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 thread-safe if many different ways if iterators of said type are being used in multiple threads.
Is the dynamic type lookup on every iteration necessary too? Would failing to do so cause crashes if evil iterator reassigns self.__class__ or something? I feel like if segfaults aren't a possibility (I haven't been able to cause one on Py 3.5 by reassigning the class's __next__ or the instance's __class__), it's not our job to fix intentionally broken code at the expense of all other code. Raymond okayed the previous issue because it was a segfaulting bug, but it seems like this is just a "broken code is broken" bug. ---------- nosy: +josh.r _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30049> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
