[Python-Dev] Please reconsider PEP 479. (original) (raw)

Guido van Rossum guido at python.org
Sat Nov 29 01:55:26 CET 2014

Thanks for being a good sport, Raymond! I've probably spent too much time fretting about this, so thanks for the reminder. I want to get back to other things too, in particular the type hinting PEP: there's a draft, but there are many things we --the co-authors-- want to change before we bother the community with another review. And that one will certainly take longer than five days!

On Fri, Nov 28, 2014 at 12:01 PM, Raymond Hettinger < raymond.hettinger at gmail.com> wrote:

On Nov 27, 2014, at 8:52 AM, Guido van Rossum <guido at python.org> wrote: I understand that @allowimportstop 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 @allowstopimport 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/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

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20141128/e63c9829/attachment-0001.html>

More information about the Python-Dev mailing list