On Aug 28, 10:37 pm, Joshua Judson Rosen <roz...@geekspace.com> wrote:
> 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....
STORE_SUBSCR has to look up the position in the hash table to store
the value, hence the second lookup.
> > > > 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".
This has nothing to do with value comparison. I was talking about key
comparison, which happens when looking up a position in a hash table.
I was the first person to use the word "lookup" in this thread and I
specifically meant hash-table position lookup.
> 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?
Well it doesn't apply specifically to the OP's problem. I changed the
topic a bit by making it specific to dicts. Is that ok with you? Was
that not allowed?
The OP can add a method like apply_to_value to his own class, but one
can't do that for dicts. Ergo why something like apply_to_value()
would be useful enough in rare circumstances where lookup is very slow
to merit a moments consideration before being rejected.
(If dict did have a method like that, the OP would at least know which
method to override.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
