deprecation of has_key?

[nicksjacobson]

I haven't heard of any plans to deprecate the dictionary has_key
method, as the "in" keyword makes it obsolete.

i.e.
if key in dict:

instead of
if dict.has_key():


Is there some reason to keep has_key?

--Nick

 

[Steve Holden]

I haven't heard of any plans to deprecate the dictionary has_key
method, as the "in" keyword makes it obsolete.

i.e.
if key in dict:

instead of
if dict.has_key():


Is there some reason to keep has_key?

Two words: backward compatibility. To lose that method now would break
thousands of existing programs. The 2.4 library would probably
experience breakage too ... let's see:

$ find /lib/python2.4/ -name "*.py" -exec grep has_key {} \; | wc -l
587

Oops!

The method might disappear in Python 3.0, when we will be allowed to
break backward compatibility - you are correct in saying it's no longer
necessary.

regards
Steve

 

[Steve Holden]

Hello,




Is there any interest in changing that to the "key in dict" sintax?

The general principles on which maintenance is based for Python decree
that such changes not be made gratuitously: the code as it is works now,
so it is only worth changing when has_key is removed.

If a module were being edited for other reasons there would be no
objection to removal of the has_key usage then, but the chance of
breakage due to careless modification is high enough to want to avoid it
unless really *necessary*.

regards
Steve

 

[Denis S. Otkidach]

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.

 

[Steven Bethard]

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().

Huh? I'm not following your logic. Why is "item in dict" less readable
than "dict.has_key(item)"? Something to do with expecting inverses that
don't exist?

Personally, I use "item in dict" because it's quite readable to me, and
generally faster.

STeVe

 

[Denis S. Otkidach]

On Thu, 21 Apr 2005 08:50:25 -0600 Steven Bethard wrote:

SB> Huh? I'm not following your logic. Why is "item in dict" less
SB> readable than "dict.has_key(item)"? Something to do with expecting
SB> inverses that don't exist?
SB>
SB> Personally, I use "item in dict" because it's quite readable to me,
SB> and generally faster.

For me dictionary is a collection of key-value pairs, but not a
collection of keys (that's what set is).

 

[Steven Bethard]

On Thu, 21 Apr 2005 08:50:25 -0600 Steven Bethard wrote:

SB> Huh? I'm not following your logic. Why is "item in dict" less
SB> readable than "dict.has_key(item)"? Something to do with expecting
SB> inverses that don't exist?
SB>
SB> Personally, I use "item in dict" because it's quite readable to me,
SB> and generally faster.

For me dictionary is a collection of key-value pairs, but not a
collection of keys (that's what set is).

Ahh, ok. Now I understand. I think you could probably search the
python-dev archives and see why the decision was made as it was. For
pretty much all my purposes, "key in dict" is much more useful than
"item in dict". Practicality beats Purity and all.

STeVe

 

[Fredrik Lundh]

Ahh, ok. Now I understand. I think you could probably search the
python-dev archives and see why the decision was made as it was. For
pretty much all my purposes, "key in dict" is much more useful than
"item in dict". Practicality beats Purity and all.

well, for all my purposes, I find that "dict.get(key)" (or sometimes "dict[key]"
is a lot more useful than has_key and in...

</F>

 

[Steven Bethard]

Ahh, ok. Now I understand. I think you could probably search the
python-dev archives and see why the decision was made as it was. For
pretty much all my purposes, "key in dict" is much more useful than
"item in dict". Practicality beats Purity and all.

well, for all my purposes, I find that "dict.get(key)" (or sometimes
"dict[key]" is a lot more useful than has_key and in...

True enough. Grepping through my (small) code base, I found only five
uses of "key in dict" style code...

STeVe

 

[Terry Reedy]

Ahh, ok. Now I understand. I think you could probably search the
python-dev archives and see why the decision was made as it was. For
pretty much all my purposes, "key in dict" is much more useful than "item
in dict". Practicality beats Purity and all.

In '[for] x in mydict:', x could potentially be key, value, or item-pair.
All three were considered and discussed -- I believe on clp-- and key
chosen as the most useful. A specific analogy brought forth was the phone
book, a mapping of names to phone number and maybe address. The decision
was definite closer to a coin-toss to a no-brainer.

Terry J. Reedy

 

[John Roth]

Ahh, ok. Now I understand. I think you could probably search the
python-dev archives and see why the decision was made as it was. For
pretty much all my purposes, "key in dict" is much more useful than "item
in dict". Practicality beats Purity and all.

In '[for] x in mydict:', x could potentially be key, value, or item-pair.
All three were considered and discussed -- I believe on clp-- and key
chosen as the most useful. A specific analogy brought forth was the phone
book, a mapping of names to phone number and maybe address. The decision
was definite closer to a coin-toss to a no-brainer.

I actually use the item-pair more frequently, but it's not
something that concerns me overmuch. I don't really worry
about a few extra keystrokes; just a whole lot of extra
keystrokes.

John Roth

 

[Just]

Ahh, ok. Now I understand. I think you could probably search the
python-dev archives and see why the decision was made as it was. For
pretty much all my purposes, "key in dict" is much more useful than "item
in dict". Practicality beats Purity and all.

In '[for] x in mydict:', x could potentially be key, value, or item-pair.
All three were considered and discussed -- I believe on clp-- and key
chosen as the most useful. A specific analogy brought forth was the phone
book, a mapping of names to phone number and maybe address. The decision
was definite closer to a coin-toss to a no-brainer.

The main argument was that nothing but "key in d" made sense (for
__contains__), and that therefore "for key in d" was the only option,
for symmetry with the other "in".

Just