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]

Michele Petrazzo wrote:

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]

On Fri, 30 Jun 2006 10:19:46 +0000, Michele Petrazzo wrote:

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]

Fredrik Lundh wrote:

Michele Petrazzo wrote:

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

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

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

Thanks,
Michele

[Bruno Desthuilliers]

Michele Petrazzo wrote:

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.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Michele Petrazzo]

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?

Michele

[Fredrik Lundh]

Michele Petrazzo wrote:

key in dict
new syntax (2.3 and later).

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]

Fredrik Lundh wrote:

Michele Petrazzo wrote:

key in dict
new syntax (2.3 and later).

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

what's "it" in this sentence?

It, is the thought that the new 2.3 introduce.

Michele

[André]

Michele Petrazzo wrote:

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?

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]

André wrote:

Michele Petrazzo wrote:

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?

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

[looping]

Michele Petrazzo wrote:

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?

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]

Michele Petrazzo wrote:

Michele Petrazzo wrote:

> key in dict
new syntax (2.3 and later).
So, following it, it can be used for the operations like len?

what's "it" in this sentence?

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>

[Fredrik Lundh]

"André" wrote:

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>

[Bruno Desthuilliers]

looping wrote:

Michele Petrazzo wrote:

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)

(snip)

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Bruno Desthuilliers]

Fredrik Lundh wrote:

"André" wrote:

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...
now, if the OP had been interested in the associated value, things might have
been a bit different.

</F>

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Georg Brandl]

Bruno Desthuilliers wrote:

looping wrote:

Michele Petrazzo wrote:

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

[Paul McGuire]

"Michele Petrazzo" <mi**************@TOGLIunipex.it> wrote in message
news:zZ********************@twister1.libero.it...

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)

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]

Bruno Desthuilliers wrote:

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

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>

[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:

import collections def ExpensiveObjectToCreate(): .... 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:
class mydict(dict): .... 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]

Fredrik Lundh wrote:

Bruno Desthuilliers wrote:

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

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>

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.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Bruno Desthuilliers]

Georg Brandl wrote:

Bruno Desthuilliers wrote:

looping wrote:

Michele Petrazzo wrote:

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)

Yes - but :
1/ not everybody knows that dict.get() takes a second optional param.
Note that, while it happens that the default return value of dict.get()
is the same as in the above example, but it may not have been the case.

2/ Since dict.get() implicitely returns None while getattr() defaults to
raising an AttributeError unless you provide a default, I prefer to be
very explicit when using dict.get().
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Alex Martelli]

Fredrik Lundh <fr*****@pythonware.com> wrote:

Michele Petrazzo wrote:

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

Fine with Python 2.2 as well, actually -- so, "new" only in an
_extremely_ loose sense of the word:-).
Alex

[Eric Deveaud]

Bruno Desthuilliers wrote:

Fredrik Lundh wrote:

Bruno Desthuilliers wrote:

on my machine, "key in dict" is about twice as fast as the full

try/getitem construct when the key is present in the dict,

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>

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.

maybee we can imagine that key in dict
just perform
try:
dict[key]
return True
except KeyError:
return False

If I understand correctly, it will be time constant no ??
just the needed time to compute the hash for the key

Eric

[Fredrik Lundh]

Bruno Desthuilliers wrote:

Seems that if "key in dict" do a simple linear search

that would be rather silly.

hint: http://pyref.infogami.com/__contains__

</F>

[Bruno Desthuilliers]

Fredrik Lundh wrote:

Bruno Desthuilliers wrote:

Seems that if "key in dict" do a simple linear search

that would be rather silly.

hint: http://pyref.infogami.com/__contains__

Of course. It's just me being silly...

:(
Thanks F
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Georg Brandl]

Bruno Desthuilliers wrote:

value = dict.get(key, None)

value = dict.get(key)

Yes - but :
1/ not everybody knows that dict.get() takes a second optional param.
Note that, while it happens that the default return value of dict.get()
is the same as in the above example, but it may not have been the case.

2/ Since dict.get() implicitely returns None while getattr() defaults to
raising an AttributeError unless you provide a default, I prefer to be
very explicit when using dict.get().

You're right, and I would write that with explicit None too.
Just wanted to continue the shortening ;)

Georg