Phillip J. Eby wrote: > At 03:51 PM 12/3/2007 -0800, Guido van Rossum wrote: >> On Dec 3, 2007 3:48 PM, Phillip J. Eby <pje at telecommunity.com> wrote: >> > Actually, you're missing the part where such evil code *can't* muck >> > things up for class dictionaries. Type dicts aren't reachable via >> > ordinary Python code; you *have* to modify them via setattr. (The >> > __dict__ of types returns a read-only proxy object, so the most evil >> > rich compare you can imagine still can't touch it.) >> >> What's to prevent that evil comparison to call setattr on the class? > > If you're caching values, it should be sufficient to have setattr > trigger the invalidation. For entries, I have to admit I don't > understand the approach well enough to make a specific proposal. As long as you could determine whether PyDict_SetItem inserted a new key, it would make sense. (If it only updates a value, the cache doesn't need to change because the pointer to the entry is still valid and the entry points to the new value.) The PyDict_SetItem API would have to change, or the dict would have to somehow pass the information out-of-bound. Neither option sounds great to me, so I'd go with caching values from setattr. Neil
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