[MERGE] remove has_key() usage

[Brian Harring]

On Tue, Aug 29, 2006 at 04:35:05PM -0500, John Arbash Meinel wrote:
> Robey Pointer wrote:
> > I've posted a branch at:
> > 
> >     http://www.lag.net/~robey/code/bzr.dev.no_has_key/
> > 
> > which removes the remaining usage of [dict].has_key() that I found in
> > bzr.dev.  No new features were added, no bugs were fixed, and nothing
> > really was accomplished except housekeeping.  It just kept me busy on
> > the train.  :)
> > 
> > Patch attached for review.
> > 
> > robey
> > 
> > 
> 
> Is there any particular reason why 'x in foo' is better than
> 'foo.has_key(x)'? I suppose 'in' is supported by more than just dicts
> (sets, lists, etc).
> Just wondering if there is some python advice that I haven't heard of.

1) slightly faster
$ python -m timeit -s 'd=dict([(x,None) for x in xrange(1000)]);' 'd.has_key(500)'
1000000 loops, best of 3: 1.48 usec per loop
$ python -m timeit -s 'd=dict([(x,None) for x in xrange(1000)]);' '500 in d'
1000000 loops, best of 3: 1.02 usec per loop

Why that's faster, as far as I know it comes down to the fact the 
interpretter does the __contains__ getattr rather then the python code 
triggering it itself; might just be that it is less opcodes; either 
way, consistantly faster in my experience.

2) it relies on the general containment protocol rather then a dict 
specific method; code can work with any sequence without having to be 
changed if it relies on __contains__ instead of the dict specific 
containment method.

Most sane code just sets has_key for dicts to
def has_key(self, key):
  return key in self

rather then maintaining anyways. :)

~brian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060829/586e2482/attachment.pgp