[Python-Dev] defaultdict proposal round three

[Fuzzyman]

Guido van Rossum wrote:

>On 2/21/06, Fuzzyman <fuzzyman at voidspace.org.uk> wrote:
>  
>
>>I've had problems in code that needs to treat strings, lists and
>>dictionaries differently (assigning values to a container where all
>>three need different handling) and telling the difference but allowing
>>duck typing is *problematic*.
>>    
>>
>
>Consider designing APIs that don't require you to mae that kind of
>distinction, if you're worried about edge cases and classifying
>arbitrary other objects correctly. It's totally possible to create an
>object that behaves like a hybrid of a string and a dict.
>
>  
>
Understood.

>If you're only interested in classifying the three specific built-ins
>you mention, I'd check for the presense of certain attributes:
>hasattr(x, "lower") -> x is a string of some kind; hasattr(x, "sort")
>-> x is a list; hasattr(x, "update") -> x is a dict. Also, hasattr(x,
>"union") -> x is a set; hasattr(x, "readline") -> x is a file.
>
>That's duck typing!
>  
>
Sure, but that requires a "dictionary like object" to define an update
method, and a "list like object" to define a sort method.

The mapping and sequence protocols are so loosely defined that some
arbitrary decision like this has to be made. (Any object that defines
"__getitem__" could follow either or both and duck typing doesn't help
you unless you're prepared to make an additional requirement that is
outside the loose requirements of the protocol.)

I can't remember how we solved it, but I think we decided that an object
would be treated as a string if it passed isinstance, and a dictionary
or sequence if it has _getitem__ (but isn't a string instance or
subclass). If it has update as well as __getitem__ it is a
"dictionary-alike".

All the best,

Michael Foord

>--
>--Guido van Rossum (home page: http://www.python.org/~guido/)
>
>  
>