This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steven.daprano
Recipients Bryan Koch, steven.daprano
Date 2019-01-17.06:05:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20190117060536.GE13616@ando.pearwood.info>
In-reply-to <1547693979.62.0.927229132748.issue35756@roundup.psfhosted.org>
Content
> I understood the PEP to include `return expr` in the iteration values 
> as per the first bullet of the proposal.
> 
> > Any values that the iterator yields are passed directly to the caller.
> 
> This bullet doesn't have any additional formatting on the word 
> "yields" so I consider it as not directly referring to the "yield" 
> keyword.

I read it as "yields", not "yields or returns". Lack of formatting is 
irrelevant -- we shouldn't expect every use of a word with a technical 
meaning to necessarily be formatted specifically.

Read the Proposal section:

    The following new expression syntax will be allowed in the body 
    of a generator 
    [...]
    FURTHERMORE, when the iterator is another generator, the 
    subgenerator is allowed to execute a return statement with a 
    value, AND THAT VALUE BECOMES THE VALUE OF THE YIELD FROM 
    EXPRESSION. [emphasis added]

https://legacy.python.org/dev/peps/pep-0380/#id11

It does not say "that value is yielded and then becomes the value of the 
yiueld from expression".

To me, it is clear that the intention here is that the return value is 
not yielded.

The Abstract also says:

    Additionally, the subgenerator is allowed to return with a
    value, and the value IS MADE AVAILABLE to the delegating
    generator. [emphasis added]

The use of "is made available" suggests that the return value is treated 
differently from a yield. Values yielded from the subgenerator are 
automatically yielded from the calling generator, without any additional 
effort. The value returned is merely *made available*, for the calling 
generator to do with whatever it wishes.

And if there is still any doubt, there is specification of the behaviour 
of "result = yield from expression" which makes it clear that the return 
value carried by the StopIteration exception is not yielded, but used as 
the value of the expression (i.e. assigned to `result`).

The motivation of yield from returning a value is to allow a side- 
channel independent of the iterable values. It isn't intended as a "one 
last yield and then bail out". I don't think that your interpretation 
can be justified by reading the PEP.

> Essentially, allowing `return expr` in generator functions without 
> invoking the generator using `yield from generator` will lose the last 
> value.

No, because the return value is not intended to be used as one of the 
iteration values. Quoting one of Greg Ewing's examples:

    I hope it is also clear why returning values via yield,
    or having 'yield from' return any of the yielded values,
    would be the wrong thing to do. The send/yield channel and
    the return channel are being used for completely different
    purposes, and conflating them would be disastrous.

http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/yf_current/Examples/Parser/parser.txt

That example is indirectly linked to from the PEP.
History
Date User Action Args
2019-01-17 06:05:44steven.dapranosetrecipients: + steven.daprano, Bryan Koch
2019-01-17 06:05:43steven.dapranolinkissue35756 messages
2019-01-17 06:05:42steven.dapranocreate