explicit protocols and duck typing

Terry Reedy tjreedy at udel.edu
Sun Jan 27 19:26:46 EST 2008


<dg.google.groups at thesamovar.net> wrote in message 
news:5e28034f-a20f-4aa7-b299-9c9132ef2566 at c4g2000hsg.googlegroups.com...
| Hi all,
|
| As I understand it, the idea behind duck typing is that you just take
| an object and if it has the methods you want to use you use it
| assuming it to be the right type of object. I'm interested in
| extending this idea a bit, but I feel the sort of thing I have in mind
| has already been thought of. So for example, in the program I'm
| writing a 'state variable' specifier can be either an integer or a
| string (the string name is mapped to an integer by another function
| getvarindex(name)).

Why a function rather than a dict 'varindex'?  The valid strings are then 
varindex.keys().  You might want a build_varindex() func though.

|In this case, I can't do duck typing by seeing if
| the object has a method or not, because both of the types are built in
| types.

builtin types have methods same as user types.

It is not clear from your description why there should be any restriction 
on state-variable specifier other than hashable since any set of hashable 
objects can be easily mapped to range(len(<specifier-set>) with a dict.

Whether you merely document the rules or write code to enforce them should 
partly depends on who suffers when they are broken.

tjr






More information about the Python-list mailing list