Way for see if dict has a key

[Michele Petrazzo]

Hi ng,
what the preferred way for see if the dict has a key?
We have a lot of solutions:

key in dict
key in dict.keys()
dict.has_key(key)
....

but what the better or the more "pythonic"?

Thanks,
Michele

 

[Fredrik Lundh]

what the preferred way for see if the dict has a key?
We have a lot of solutions:

key in dict

new syntax (2.3 and later).

key in dict.keys()

inefficient and pointless.

dict.has_key(key)

old syntax; use for code that needs to be backwards compatible.

but what the better or the more "pythonic"?

see above.

</F>

 

[Chance Ginger]

Hi ng,
what the preferred way for see if the dict has a key?
We have a lot of solutions:

key in dict
key in dict.keys()
dict.has_key(key)
...

but what the better or the more "pythonic"?

Thanks,
Michele

It is a religious call....

 

[Michele Petrazzo]

new syntax (2.3 and later).

So, following it, it can be used for the operations like len?

len(dict) -> len(dict.keys()) ?

Thanks,
Michele

 

[Bruno Desthuilliers]

Hi ng,
what the preferred way for see if the dict has a key?
We have a lot of solutions:

key in dict
key in dict.keys()
dict.has_key(key)
...

try:
dict[key]
except KeyError:
...
else:
...

but what the better

Depends on the context.

 

[Fredrik Lundh]

So, following it, it can be used for the operations like len?

what's "it" in this sentence?

len(dict) -> len(dict.keys()) ?

len(dict.keys()) is a lousy way to spell len(dict).

</F>

 

[Michele Petrazzo]

Depends on the context.

If know only one context: see if the key are into the dict... What other
context do you know?

Michele

 

[Michele Petrazzo]

what's "it" in this sentence?

It, is the thought that the new 2.3 introduce.

Michele

 

[=?iso-8859-1?B?QW5kcuk=?=]

If know only one context: see if the key are into the dict... What other
context do you know?

Michele

Perhaps Bruno meant this:

try:
... my_dict[key] ...
except:
....

when we expect that the key will most often be in my_dict so that
exception will be raised rarely, otherwise use

if key in dict

André

 

[Michele Petrazzo]

If know only one context: see if the key are into the dict... What other
context do you know?

Michele

Perhaps Bruno meant this:

try:
... my_dict[key] ...
except:
....

Yes I see

when we expect that the key will most often be in my_dict so that
exception will be raised rarely

I didn't thought this because if I think that a key aren't in a dict, I
use dict.get(key, default)

otherwise use if key in dict

André

Thanks to all,
Michele

 

[Fredrik Lundh]

Perhaps Bruno meant this:

try:
... my_dict[key] ...
except:
...

when we expect that the key will most often be in my_dict so that
exception will be raised rarely, otherwise use

on my machine, "key in dict" is about twice as fast as the full try/getitem con-
struct when the key is present in the dict, so that's not a very good optimization.

now, if the OP had been interested in the associated value, things might have
been a bit different.

</F>

 

[looping]

If know only one context: see if the key are into the dict... What other
context do you know?

Michele

Why do you want to do that ?

if key in dict:
value = dict[key]
else:
value = None

could be write:

try:
value = dict[key]
except KeyError:
value = None

so depends of the context...

 

[Fredrik Lundh]

It, is the thought that the new 2.3 introduce.

support for "key in dictionary" form was added in 2.3 (in earlier versions,
"in" was only supported for sequences, not for mappings).

len(dictionary) works in all Python versions.

</F>

 

[Bruno Desthuilliers]

If know only one context: see if the key are into the dict... What other
context do you know?

Why do you want to do that ?

if key in dict:
value = dict[key]
else:
value = None

could be write:

value = dict.get(key, None)

(snip)

 

[Bruno Desthuilliers]

:

Perhaps Bruno meant this:

try:
... my_dict[key] ...
except:
...

when we expect that the key will most often be in my_dict so that
exception will be raised rarely, otherwise use

on my machine, "key in dict" is about twice as fast as the full try/getitem con-
struct when the key is present in the dict,

Doesn't it depends on the number of keys in the dict ?

so that's not a very good optimization.

FWIW, I personaly didn't meant to present it as an optimisation - just
as one more possible way to test the existence of a given key...

 

[Paul McGuire]

I didn't thought this because if I think that a key aren't in a dict, I
use dict.get(key, default)

Another factor to consider is if "default" is not something simple like 0 or
None, but is an object constructed and initialized with some expensive
initialization code (like access to a database). In this case:

dict.get(key, ExpensiveObjectToCreate())

always creates the default value, and if the key does not exist, then
promptly drops it on the floor.

In such a case you'd be better off with one of the "check for existence"
patterns, which only creates the default value if you *know* you're going to
need it.

-- Paul

 

[Fredrik Lundh]

Doesn't it depends on the number of keys in the dict ?

why would it depend on the number of keys in the dict ?

</F>

 

[Georg Brandl]

Bruno Desthuilliers wrote:

but what the better

Depends on the context.


If know only one context: see if the key are into the dict... What other
context do you know?

Why do you want to do that ?

if key in dict:
value = dict[key]
else:
value = None

could be write:

value = dict.get(key, None)

value = dict.get(key)



Georg

 

[Fredrik Lundh]

Paul McGuire wrote:

Another factor to consider is if "default" is not something simple like 0 or
None, but is an object constructed and initialized with some expensive
initialization code (like access to a database). In this case:

dict.get(key, ExpensiveObjectToCreate())

always creates the default value, and if the key does not exist, then
promptly drops it on the floor.

In such a case you'd be better off with one of the "check for existence"
patterns, which only creates the default value if you *know* you're going to
need it.

unless you're targeting 2.5 or later, in which case you can use the
defaultdict class:
.... print "creating an expensive object"
.... return "expensive object"
....

>>> d = collections.defaultdict(ExpensiveObjectToCreate)
>>> d["key"]

creating an expensive object
'expensive object'

>>> d["key"]

'expensive object'

or, if you prefer, the new __missing__ hook:
.... def __missing__(self, key):
.... print "add new object base on", key
.... value = "new object"
.... self[key] = value
.... return value
....

>>> d = mydict()
>>> d["key"]

add new object base on key
'new object'

>>> d["key"]

'new object'

</F>

 

[Bruno Desthuilliers]

why would it depend on the number of keys in the dict ?

</F>

Seems that if "key in dict" do a simple linear search, it depends on the
number of keys in dict (and the position of the searched key etc...).

And if I'm missing the point and you it and you know why, it would be
simple to explain than to answer my question with another question.