This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Will Roberts
Recipients MSeifert, Will Roberts, mark.dickinson, rhettinger, serhiy.storchaka
Date 2017-06-05.12:40:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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?
Date User Action Args
2017-06-05 12:40:27Will Robertssetrecipients: + Will Roberts, rhettinger, mark.dickinson, serhiy.storchaka, MSeifert
2017-06-05 12:40:26Will Robertssetmessageid: <>
2017-06-05 12:40:26Will Robertslinkissue30537 messages
2017-06-05 12:40:26Will Robertscreate