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

[Guido van Rossum]

I'd be wary of going too far here. The parser (which uses a different
representation for the grammar) may not support all of these -- in
particular I would guess that the syntax for subscriptions is actually more
complicated than shown, because of slices. Do you allow a[x:y, *rest]?

On Thu, Nov 30, 2017 at 10:27 AM, Brett Cannon <brett at python.org> wrote:

>
>
> 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
>>
>
> _______________________________________________
> 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/
> guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171130/107450f6/attachment.html>