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.hettin...@gmail.com> wrote: > > On Nov 27, 2014, at 8:52 AM, Guido van Rossum <gu...@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/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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
