Carl Banks <pavlovevide...@gmail.com> writes:
>
> On Aug 28, 2:42 pm, Terry Reedy <tjre...@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)))).
--
http://mail.python.org/mailman/listinfo/python-list
