Overriding iadd for dictionary like objects

Joshua Judson Rosen rozzin at geekspace.com
Sat Aug 29 07:37:21 CEST 2009


Carl Banks <pavlovevidence at gmail.com> writes:
>
> On Aug 28, 2:42 pm, Terry Reedy <tjre... at udel.edu> wrote:
>
> > Carl Banks wrote:
> > > I don't think it needs a syntax for that, but I'm not so sure a method
> > > to modify a value in place with a single key lookup wouldn't
> > > occasioanally be useful.
> >
> > Augmented assignment does that.
> 
> Internally uses two lookups, one for getting, and one for setting.
>
> I think this is an unavoidable given Python's semantics.  Look at
> the traceback:
> 
> 
> >>> def x():
> ...     d['a'] += 1
> ...
> >>> dis.dis(x)
>   2           0 LOAD_GLOBAL              0 (d)
>               3 LOAD_CONST               1 ('a')
>               6 DUP_TOPX                 2
>               9 BINARY_SUBSCR

OK, there's one lookup, but...

>              10 LOAD_CONST               2 (1)
>              13 INPLACE_ADD
>              14 ROT_THREE
>              15 STORE_SUBSCR
>              16 LOAD_CONST               0 (None)
>              19 RETURN_VALUE

... I don't see anything in there that retrieves the value a second time....

> > > As a workaround, if lookups are expensive,
> >
> > But they are not. Because (C)Python is heavily based on dict name lookup
> > for builtins and global names and attributes, as well as overt dict
> > lookup, must effort has gone into optimizing dict lookup.
> 
> The actual lookup algorithm Python dicts use is well-optimized, yes,
> but the dict could contain keys that have expensive comparison and
> hash-code calculation, in which case lookup is going to be slow.

I'll like the originator correct me if I've made a mistake, but I read
"lookup" as actually meaning "lookup", not "value-comparison".

At least in part because the question, as it was posed, specifically
related to a wrapper-class (providing a mapping ("dict like") interface)
around a database of some sort other than Python's dict class per se.

How do the details of Python's native dict-type's internal (hashtable)
algorithm matter when they're explicitly /not/ being used?

-- 
Don't be afraid to ask (Lf.((Lx.xx) (Lr.f(rr)))).



More information about the Python-list mailing list