Georg Brandl wrote: > Nick Coghlan schrieb: >> Armin Ronacher wrote: >>> Speaking of atom keys() / values() / items() operations: I guess we will >>> see more of those problems in threaded situations when people start to >>> convert code over to Python. I've seen quite a few situations where code >>> relays on keys() holding the interpreter lock. >> list(iter) doesn't re-enter the eval loop if the iterator is written in >> C and hence won't let go of the GIL. As I believe the dict views in 3.0 >> are all C classes, I'd like to see a failing test case along these lines >> that doesn't involve a dict subclass and code written in Python. > > WeakKeyDictionary.keys() iterates over its .data dictionary's keys() instead > of list(data.keys()). Therefore, the user of WeakKeyDictionary has no chance > to do list(keys()) without running Python code.
Ouch, there's the dict subclass with Python code that I was asking for before I got concerned (I forgot that the weakref module is only partially implemented in C). I agree this is a problem, but I'm struggling to think of possible solutions that aren't either horrendously complicated or completely contrary to the idea of view-based dicts. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org _______________________________________________ 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