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