Showing content from http://mail.python.org/pipermail/python-dev/attachments/20141128/365cc669/attachment.html below:
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 27, 2014, at 8:52 AM, Guido van Rossum <<a href="mailto:guido@python.org" class="">guido@python.org</a>> wrote:</div><div class=""><div dir="ltr" style="font-family: ArialMT; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra">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.<br class=""><br class="">- It means we're forever stuck with two possible semantics for StopIteration raised in generators.<br class=""><br class="">- 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.<br class=""><br class="">- I don't actually know whether other Python implementations have the ability to copy code objects to change flags.<br class=""><br class=""></div><div class="gmail_extra">- 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.<br class=""><br class=""></div><div class="gmail_extra">- Its existence encourage people to use the decorator in favor of fixing their code properly.<br class=""><br class=""></div><div class="gmail_extra">- 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.)<br class=""></div></div></div></blockquote></div><br class=""><div class="">I concur. PEP 479 fixes are trivially easy to do without a decorator.</div><div class=""><br class=""></div><div class="">After Guido pronounced on the PEP, I fixed-up several parts of the standard library in just a few minutes. It's not hard.</div><div class=""><a href="https://mail.python.org/pipermail/python-checkins/2014-November/133252.html" class="">https://mail.python.org/pipermail/python-checkins/2014-November/133252.html</a></div><div class=""><a href="https://mail.python.org/pipermail/python-checkins/2014-November/133253.html" class="">https://mail.python.org/pipermail/python-checkins/2014-November/133253.html</a></div><div class=""><br class=""></div><div class="">Also, I'm submitting a 479 patch to the Django project so we won't have to worry about this one.</div><div class=""><br class=""></div><div class="">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").</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Raymond</div></body></html>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4