On Tue, Mar 18, 2014 at 4:21 PM, Steven D'Aprano <st...@pearwood.info> wrote: > On Tue, Mar 18, 2014 at 01:21:05PM +0200, Maciej Fijalkowski wrote: > >> note that this is specifically about dicts, where __eq__ will be >> called undecided number of times anyway (depending on collisions in >> hash/buckets which is implementation specific to start with) > > Exactly. Using a __eq__ method with side-effects is a good way to find > out how many collisions your dict has :-) > > But specifically with your example, > > if x in d: > return d[x] > > my sense of this is that it falls into the same conceptual area as the > identity optimization for checking list or set containment: slightly > unclean, but justified. Provided d is an actual built-in dict, and it > hasn't been modified between one call and the next, I think it would be > okay to optimize the second lookup d[x]. > > A question: how far away will this optimization apply? > > if x in d: > do_this() > do_that() > do_something_else() > spam = d[x]
it depends what those functions do. JIT will inline them and if they're small, it should work (although a modification of a different dict is illegal, since aliasing is not proven), but at some point it'll give up (Note that it'll also give up with a call to C releasing GIL since some other thread can modify it). _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
