At 12:27 PM 12/3/2007 -0700, Neil Toronto wrote: >Guido van Rossum wrote: > > On Dec 2, 2007 12:49 PM, Neil Toronto <ntoronto at cs.byu.edu> wrote: > >> It turned out not *that* hard to code around for attribute caching, and > >> the extra cruft only gets invoked on a cache miss. The biggest problem > >> isn't speed - it's that it's possible (though extremely unlikely), while > >> testing keys for equality, that a rich compare alters the underlying > >> dict. This causes the caching lookup to have to try to get an entry > >> pointer again, which could invoke the rich compare, which might alter > >> the underlying dict.. > > > > How about subclasses of str? These have all the same issues... > >Yeah. I ended up having it, per class, permanently revert to uncached >lookups when it detects that a class dict in the MRO has non-string >keys. That's flagged by lookdict_string, which uses PyString_CheckExact. I'm a bit confused here. Isn't the simplest way to cache attribute lookups to just have a cache dictionary in the type, and update that dictionary whenever a change is made to a superclass? That's essentially how __slotted__ attribute changes on base classes work now, isn't it? Why do we need to mess around with the dictionary entries themselves in order to do that?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4