deprecation of has_key?

Denis S. Otkidach ods at strana.ru
Thu Apr 21 10:36:01 EDT 2005


On Thu, 21 Apr 2005 05:43:36 -0400 Steve Holden wrote:

SH> Two words: backward compatibility. To lose that method now would
SH> break thousands of existing programs.
[...]
SH> The method might disappear in Python 3.0, when we will be allowed to
SH> break backward compatibility - you are correct in saying it's no
SH> longer necessary.

I believe it's a bad idea to remove this method, since behavior of both
"item in dict" and "for item in dict" (especially the later) in Python
does't seem sane to me.  Just look at reverse operations:

dict.fromkeys(seq) <-> d.keys(), d.iterkeys() - OK
dict(iterable) <-> d.iteritems()              - why not iter(d)?
dict(l) <-> d.items()                         - why not list(d)?
dict(seq) <-> d.keys(), d.iterkeys()          - looks very strange.

And those ("item in dict" and "for item in dict") are related of course,
since the following should pass:

for item in d:
    assert item in d

That's the reason why I always prefer to use has_key() and iteritems()
to in and iter().  Readability counts.

-- 
Denis S. Otkidach
http://www.python.ru/      [ru]



More information about the Python-list mailing list