Phillip J. Eby wrote: > At 03:26 PM 12/3/2007 -0700, Neil Toronto wrote: >> Phillip J. Eby wrote: >> > At 12:27 PM 12/3/2007 -0700, Neil Toronto wrote: >> Some version of the non-string keys problem would exist with any caching >> mechanism, though. An evil rich compare can always monkey about with >> class dicts in the MRO. If a caching scheme caches values and doesn't >> account for that, it could return stale values. If it caches entries and >> doesn't account for that, it could segfault. I suppose you could argue >> that returning stale values is fitting punishment for using an evil rich >> compare, though the punishee isn't always the same person as the >> punisher. > > 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.)
Interesting. But I'm going to have to say it probably wouldn't work as well, since C code can and does alter tp_dict directly. Those places in the core would have to be altered to invalidate the cache. There's also the issue of extensions, which so far have been able to alter any tp_dict without problems. It'd also be really annoying for a class to have to notify all of its subclasses when one of its attributes changed. In other words, I can see the footprint being rather large and difficult to manage. By hooking right into dicts and letting them track when things change, every other piece of code in the system can happily continue doing whatever it likes without needing to worry that it might invalidate some cache entry somewhere. I'm confident that's the right design choice whether it's best to cache entries or not. I hope you don't feel that I'm just trying to be contradictory. I'm actually enjoying the discussion a lot. I'd rather have my grand ideas tested now than discover I was wrong later. Neil _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
