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 | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
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