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.
Note that I'm not saying that I know for certain that there aren't any
problems with list(d.keys()) that aren't seen with the direct list
conversion in 2.x - I'm just saying it may not be as easy to provoke
such problems as it initially appears due to the way the list
constructor interacts with the supplied iterable, so it is going to take
an actual failing test case to convince me.
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
