[Python-Dev] Please reconsider PEP 479.

[Raymond Hettinger]

> On Nov 27, 2014, at 8:52 AM, Guido van Rossum <guido at python.org> wrote:
> 
> I understand that @allow_import_stop represents a compromise, an attempt at calming the waves that PEP 479 has caused. But I still want to push back pretty hard on this idea.
> 
> - It means we're forever stuck with two possible semantics for StopIteration raised in generators.
> 
> - It complicates the implementation, because (presumably) a generator marked with @allow_stop_import should not cause a warning when a StopIteration bubbles out -- so we actually need another flag to silence the warning.
> 
> - I don't actually know whether other Python implementations have the ability to copy code objects to change flags.
> 
> - It actually introduces a new incompatibility, that has to be solved in every module that wants to use it (as you show above), whereas just putting try/except around unguarded next() calls is fully backwards compatible.
> 
> - Its existence encourage people to use the decorator in favor of fixing their code properly.
> 
> - The decorator is so subtle that it probably needs to be explained to everyone who encounters it (and wasn't involved in this PEP discussion). Because of this I would strongly advise against using it to "fix" the itertools examples in the docs; it's just too magical. (IIRC only 2 examples actually depend on this.)

I concur.  PEP 479 fixes are trivially easy to do without a decorator.

After Guido pronounced on the PEP, I fixed-up several parts of the standard library in just a few minutes.  It's not hard.
https://mail.python.org/pipermail/python-checkins/2014-November/133252.html <https://mail.python.org/pipermail/python-checkins/2014-November/133252.html>
https://mail.python.org/pipermail/python-checkins/2014-November/133253.html <https://mail.python.org/pipermail/python-checkins/2014-November/133253.html>

Also, I'm submitting a 479 patch to the Django project so we won't have to worry about this one.

I recommend that everyone just accept that the PEP is a done deal and stop adding complexity or work-arounds.  We have a lot of things going for us on this one:  1) the affected code isn't common-place (mostly in producer/consumer middleware tools created by tool makers rather than by tool users), 2) the RuntimeError is immediate and clear about both the cause and the repair, 3) the fixes are trivially easy to make (add try/except around next() calls and replace "raise StopIteration" with "return").

Ideally, everyone will let this die and go back to being with family for the holidays (or back to work if you don't have a holiday this week).


Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141128/365cc669/attachment.html>