[issue30049] Don't cache tp_iternext

2017-04-18 Thread Raymond Hettinger
Raymond Hettinger added the comment: > it seems like this is just a "broken code is broken" bug I agree. Unless there were a crasher of some sort, I prefer to keep the existing code, some of which has been deployed successfully for well over a decade. -- resolution: -> rejected

[issue30049] Don't cache tp_iternext

2017-04-17 Thread Josh Rosenberg
Josh Rosenberg added the comment: I'm having a hard time thinking of legitimate cases where replacing __next__ mid-iteration is a thing. Doing so retroactively on the class (so it changes all outstanding iterators, no matter what state they're in) seems dubious at best, and it wouldn't be

[issue30049] Don't cache tp_iternext

2017-04-12 Thread Raymond Hettinger
Changes by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___

[issue30049] Don't cache tp_iternext

2017-04-12 Thread Serhiy Storchaka
Changes by Serhiy Storchaka : -- pull_requests: +1231 ___ Python tracker ___ ___

[issue30049] Don't cache tp_iternext

2017-04-12 Thread Serhiy Storchaka
New submission from Serhiy Storchaka: Some operations cache the value of the tp_iternext slot and call it in a loop. But calling tp_iternext can run arbitrary code, release GIL and change the tp_iternext slot in the same or other thread. This can leads to visible behavior difference, such as