What's the difference ?

[Alex]

Hye,

I was just wondering what is the difference between

and

I've search a bit in the python documentation, and the only things I
found was that they are "equivalent".

But in this (quiet old) sample ( "http://aspn.activestate.com/ASPN/
Cookbook/Python/Recipe/59875" ), there is difference between the two
notation.

Thanks in advance

 

[kyosohma]

Hye,

I was just wondering what is the difference between


I've search a bit in the python documentation, and the only things I
found was that they are "equivalent".

But in this (quiet old) sample ( "http://aspn.activestate.com/ASPN/
Cookbook/Python/Recipe/59875" ), there is difference between the two
notation.

Thanks in advance

Weird. Hetland's book, "Beginning Python" states that it's a matter of
taste. Martelli's "Python Cookbook 2nd Ed." says to use the get()
method instead as you never know if a key is in the dict. However, I
can't seem to find any reference to has_key in his book.

According to Chun in "Core Python Programming", has_key will be
obsoleted in future versions of Python, so he recommends using "in" or
"not in".

There's your non-answer. Hope that helps.

Mike

 

[Marc 'BlackJack' Rintsch]

Hye,

I was just wondering what is the difference between


I've search a bit in the python documentation, and the only things I
found was that they are "equivalent".

But in this (quiet old) sample ( "http://aspn.activestate.com/ASPN/
Cookbook/Python/Recipe/59875" ), there is difference between the two
notation.

The comments in this recipes source code are misleading. Difference is
not the ``in`` but that it is used on ``another_dict.keys()`` in the "bad"
example. That is a linear search on a list with all keys instead asking
the dictionary directly like you did above.

The difference in your code above is that ``in`` works on other types too
that implement `__contains__()`, like lists or sets for example, and that
it is a bit faster as the second example has to look up the `has_key()`
method on the object first.

Ciao,
Marc 'BlackJack' Rintsch

 

[Alex Martelli]

Hye,

I was just wondering what is the difference between

Mis-spelled (no final s in the method name).

I've search a bit in the python documentation, and the only things I
found was that they are "equivalent".

Semantically they are, but `in' is faster, more concise, & readable.

But in this (quiet old) sample ( "http://aspn.activestate.com/ASPN/
Cookbook/Python/Recipe/59875" ), there is difference between the two
notation.

What that example is pointing to as "wrong way" is a NON-equivalent
approach that's extremely slow:
if my_key in mydict.keys():

The call to keys() takes time and memory to build a list of all keys,
after which the ``in'' operator, having a list as the RHS operand, is
also quite slow (O(N), vs O(1)!). So, never use that useless and silly
call to keys() in this context!


Alex

 

[Alex Martelli]

Weird. Hetland's book, "Beginning Python" states that it's a matter of
taste.

If your taste is for more verbose AND slower notation without any
compensating advantage, sure.

Martelli's "Python Cookbook 2nd Ed." says to use the get()
method instead as you never know if a key is in the dict. However, I
can't seem to find any reference to has_key in his book.

..get is not a direct alternative to ``in'' (it's an alternative to an
idiom where you key into the dict if the key is present and otherwise
supply a default value, and it's MUCH better in that case). has_key is
probably not even mentioned in the Cookbook (2nd edition) since there is
never a good need for it in the Python versions it covers (2.2 and up),
but you can probably find traces in the 1st edition (which also covered
Python back to 1.5.2, where has_key *was* needed); the Nutshell (2nd ed)
mentions it briefly in a table on p. 60.

According to Chun in "Core Python Programming", has_key will be
obsoleted in future versions of Python, so he recommends using "in" or
"not in".

Yes, we're removing has_key in Python 3.0 (whose first alpha will be out
reasonably soon, but is not going to be ready for production use for
quite a bit longer), among other redundant things that exist in 2.* only
for legacy and backwards compatibility reasons. This makes 3.0 simpler
(a little closer to the "only one obvious way" ideal).

But you should use ``in'' and ``not in'' anyway, even if you don't care
about 3.* at all, because they only have advantages wrt has_key, without
any compensating disadvantage.


Alex

 

[kyosohma]

...


If your taste is for more verbose AND slower notation without any
compensating advantage, sure.


.get is not a direct alternative to ``in'' (it's an alternative to an
idiom where you key into the dict if the key is present and otherwise
supply a default value, and it's MUCH better in that case). has_key is
probably not even mentioned in the Cookbook (2nd edition) since there is
never a good need for it in the Python versions it covers (2.2 and up),
but you can probably find traces in the 1st edition (which also covered
Python back to 1.5.2, where has_key *was* needed); the Nutshell (2nd ed)
mentions it briefly in a table on p. 60.


Yes, we're removing has_key in Python 3.0 (whose first alpha will be out
reasonably soon, but is not going to be ready for production use for
quite a bit longer), among other redundant things that exist in 2.* only
for legacy and backwards compatibility reasons. This makes 3.0 simpler
(a little closer to the "only one obvious way" ideal).

But you should use ``in'' and ``not in'' anyway, even if you don't care
about 3.* at all, because they only have advantages wrt has_key, without
any compensating disadvantage.

Alex

Martelli,

I kind of figured .get wasn't a direct alternative to "in", but I
thought the OP might be able to use it since (s)he didn't mention what
they wanted to do.

Mike

 

[Alexandre Badez]

Thanks for all you information.

I'll continue to use 'in' instead of 'has_key' for a "faster, more
concise, & readable" code (^L^ )