Will Roberts added the comment:
Thanks for feedback, Serhiy and Raymond! Github PR now has reverted changes
except to the calls in islice_new; I am happy to squash if you would like.
Serhiy, this is my first time poking around in CPython code. What are the
potential consequences of making `itertools.islice` less atomic/thread-safe,
and/or possibly releasing the GIL? Are there any gotchas to watch out for in
this patch specifically? I've modelled my changes on the code in listobject.c
[list_subscript], but I would love to hear if there's a better way to do things.
Raymond, I'd also be curious to learn about any code weirdness or inefficiency
you have in mind. I agree with you that there might not be a compelling
use-case here. The SO question looks to be a bit contrived; however, the
interesting bits to me here are that the behaviour of numpy interacting with
itertools has changed since py27, and also that the proposed
workarounds/solutions seem ... inelegant? Need a numpy integer be explicitly
coerced to int in this context when the type implements an __index__ method?
--
___
Python tracker
<http://bugs.python.org/issue30537>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
