[Python-Dev] Allow tuple unpacking in return and yield statements

[Brett Cannon]

On Thu, 30 Nov 2017 at 05:01 David Cuthbert <dacut at kanga.org> wrote:

> Henk-Jaap noted that the grammar section of the language ref for yield and
> return should also be updated from expression_list to starred_list with
> this change. As noted elsewhere, this isn't in-sync with the Grammar file
> (intentionally, if I understand correctly).
>
> I took a look, and I believe that every instance of expression_list (which
> doesn't allow the unparenthesized tuple unpacking) should be changed to
> starred_list. Which might really mean that starred_list should have never
> existed, and the changes should have been put into expression_list in the
> first place (though I understand the desire to be conservative with syntax
> changes).
>
> Here are the places where expression_list is still allowed (after fixing
> return and yield):
>
>     subscription ::= primary "[" expression_list "]"
>     augmented_assignment_stmt ::=  augtarget augop (expression_list |
> yield_expression)
>     for_stmt ::=  "for" target_list "in" expression_list ":" suite
>                   ["else" ":" suite]
>
> In other words, the following all produce SyntaxErrors today (and
> enclosing them in parentheses avoids this):
>     a[1, *rest]
>     a += 1, *rest # and other augops: -= *= /= etc.
>     for i in 1, *rest:
>
> My hunch is these cases should also be fixed to be consistent. While I
> can't see myself using something like "a += 1, *rest" in the immediate
> future, it seems weird to be inconsistent in these cases (and reinforces
> the oft-mistaken assumption, from Terry's earlier reply, that tuples are
> defined by parentheses instead of commas).
>
> Any reason I shouldn't dig in and fix this while I'm here?
>

It's really a question of ramifications. Do we want every place where
parentheses tuples are required to allow for the non-paren version? If
there was a way to get an exhaustive list of examples showing what would
change in those instances then we could make a judgement call as to whether
this change is desired.

-Brett


>
> Dave
>
>
> On 11/25/17, 9:03 PM, Nick Coghlan wrote:
>
>     On 26 November 2017 at 09:22, Terry Reedy <tjreedy at udel.edu> wrote:
>     > Since return and yield are often the first half of a cross-namespace
>     > assignment, requiring the () is a bit surprising.  Perhaps someone
> else has
>     > a good reason for the difference.
>
>     These kinds of discrepancies tend to arise because there are a few
>     different grammar nodes for "comma separated sequence of expressions",
>     which makes it possible to miss some when enhancing the tuple syntax.
>
>     Refactoring the grammar to eliminate the duplication isn't especially
>     easy,  and we don't change the syntax all that often, so it makes
>     sense to treat cases like this one as bugs in the implementation of
>     the original syntax change (except that the "don't change the Grammar
>     in maintenance releases" guideline means they still need to be handled
>     as new features when it comes to fixing them).
>
>     Cheers,
>     Nick.
>
>     P.S. That said, I do wonder if it might be feasible to write a
>     "Grammar consistency check" test that ensured the known duplicate
>     nodes at least have consistent definitions, such that missing one in a
>     syntax update will cause an automated test failure. Unfortunately, the
>     nodes typically haven't been combined because they have some
>     *intentional* differences in exactly what they allow, so I also
>     suspect that this is easier said than done.
>
>     --
>     Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171130/b31523c7/attachment.html>