What's the difference ?

[kyosohma at gmail.com]

On Aug 29, 9:44 am, al... at mac.com (Alex Martelli) wrote:
> <kyoso... at gmail.com> wrote:
>
>    ...
>
> > 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

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