<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 16 November 2014 01:56, Chris Angelico <span dir="ltr"><<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Sun, Nov 16, 2014 at 2:21 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> On 16 November 2014 00:37, Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br>
>><br>
>> On Sun, Nov 16, 2014 at 1:13 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>> >> For certain situations, a simpler and fully backward-compatible<br>
>> >> solution may be sufficient: when a generator returns, instead of<br>
>> >> raising ``StopIteration``, it raises a specific subclass of<br>
>> >> ``StopIteration`` which can then be detected. If it is not that<br>
>> >> subclass, it is an escaping exception rather than a return statement.<br>
>> ><br>
>> > There's an additional subtlety with this idea: if we add a new<br>
>> > GeneratorReturn exception as a subclass of StopIteration, then generator<br>
>> > iterators would likely also have to change to replace GeneratorReturn<br>
>> > with a<br>
>> > regular StopIteration (chaining appropriately via __cause__, and copying<br>
>> > the<br>
>> > return value across).<br>
>><br>
>> Would have to do so automatically, meaning this is no simpler than the<br>
>> current proposal? Or would have to be always explicitly written to<br>
>> handle it?<br>
><br>
> When GeneratorReturn escaped a generator frame, the interpreter would<br>
> automatically convert it into an ordinary StopIteration instance.<br>
<br>
</span>Okay, let me see if I have this straight. When a 'return' statement<br>
(including an implicit one at end-of-function) is encountered in any<br>
function which contains a 'yield' statement, it is implemented as<br>
"raise GeneratorReturn(value)" rather than as "raise<br>
StopIteration(value)" which is the current behaviour. However, if any<br>
GeneratorReturn would be raised in any way other than the 'return'<br>
statement, it would magically become a StopIteration instead. Is that<br>
correct?<br></blockquote><div><br></div><div>That's not quite how generators work. While the "returning from a generator is equivalent to raise StopIteration" model is close enough that it's functionally equivalent to the actual behaviour in most cases (with the main difference being in how try/except blocks and context managers inside the generator react), this particular PEP is a situation where it's important to have a clear picture of the underlying details.<br><br>When you have a generator iterator (the thing you get back when calling a generator function), there are two key components:<br><br></div><div>* the generator iterator object itself<br></div><div>* the generator frame where the code is running<br><br></div><div>When you call next(gi), you're invoking the __next__ method on the *generator iterator*. It's that method which restarts evaluation of the generator frame at the point where it last left off, and interprets any results.<br><br></div><div>Now, there are three things that can happen as a result of that frame evaluation:<br><br></div><div> 1. It hits a yield point. In that case, gi.__next__ returns the yielded value.<br><br> 2. It can return from the frame. In that case.
gi.__next__ creates a *new* StopIteration instance (with an appropriate
return value set) and raises it<br><br></div><div> 3. It can throw an exception. In that case, gi.__next__ just allows it to propagate out (including if it's StopIteration)<br><br></div><div>The following example illustrates the difference between cases 2 and 3 (in both cases, there's a StopIteration that terminates the hidden loop inside the list() call, the difference is in where that StopIteration is raised):<br></div><div><br>>>> def genreturn():<br>... yield<br>... try:<br>... return<br>... except:<br>... print("No exception")<br>... raise<br>... <br>>>> list(genreturn())<br>[None]<br><br>>>> def genraise():<br>... yield<br>... try:<br>... raise StopIteration<br>... except:<br>... print("Exception!")<br>... raise<br>... <br>>>> list(genraise())<br>Exception!<br>[None]<br><br>(The possible outcomes of gi.send() and gi.throw()
are the same as those of next(gi). gi.throw() has the novel variant
where the exception thrown in may propagate back out)<br><br></div><div>The two change proposals being discussed are as follows:<br><br></div><div>Current PEP (backwards incompatible): Change outcome 3 to convert StopIteration to RuntimeError (or a new exception type). Nothing else changes.<br></div><div><br></div><div>Alternative (backwards compatible): Change outcome 2 to raise GeneratorReturn instead of StopIteration and outcome 3 to convert GeneratorReturn to StopIteration.<br><br></div><div>The alternative *doesn't* do anything about the odd discrepancy between comprehensions and generator expressions that started the previous thread. It just adds a new capability where code that knows it's specifically dealing with a generator (like contextlib or asyncio) can more easily tell the difference between outcomes 2 and 3.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This does sound simpler. All the magic is in the boundary of the<br>
generator itself, nothing more. If a __next__ method raises either<br>
StopIteration or GeneratorReturn, or if any other function raises<br>
them, there's no special handling.<br></blockquote><div><br></div><div>All the magic is actually at the generator boundary regardless. The key differences between the two proposals are the decision to keep StopIteration as a common parent exception, and allow it to continue propagating out of generator frames unmodified.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Question: How does it "become" StopIteration? Is a new instance of<br>
StopIteration formed which copies in the other's ``value``? Is the<br>
type of this exception magically altered? Or is it a brand new<br>
exception with the __cause__ or __context__ set to carry the original?<br></blockquote><div><br></div><div>I'd suggest used the exception chaining machinery and creating a new exception with __cause__ and the generator return value set appropriately.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="">
</span><span class="">>> (I'm not familiar with<br>
>> contextlib2 or what it offers.)<br>
><br>
> contexlib2 ~= 3.3 era contextlib that runs as far back as 2.6 (I initially<br>
> created it as a proving ground for the idea that eventually become<br>
> contextlib.ExitStack).<br>
<br>
</span>Thanks, I figured it'd be like that. Since contextlib exists in 2.7,<br>
is contextlib2 meant to be legacy support only?<br></blockquote><div><br></div></div>contextlib has actually been around since 2.5, but some features (most notably ExitStack) weren't added until much later. Like unittest2, contextlib2 allows access to newer stdlib features on older versions (I haven't used it as a testing ground for new ideas since ExitStack).<br clear="all"></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br>Nick.<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, Australia</div>
</div></div>
翻译：