Message295185
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:27 | Will Roberts | set | recipients:
+ Will Roberts, rhettinger, mark.dickinson, serhiy.storchaka, MSeifert |
2017-06-05 12:40:26 | Will Roberts | set | messageid: <1496666426.95.0.645081390419.issue30537@psf.upfronthosting.co.za> |
2017-06-05 12:40:26 | Will Roberts | link | issue30537 messages |
2017-06-05 12:40:26 | Will Roberts | create | |
|