[Python-Dev] Non-string keys in namespace dicts

[Neil Toronto]

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