[Python-Dev] Allow tuple unpacking in return and yield statements
Guido van Rossum
guido at python.org
Thu Nov 30 22:50:57 EST 2017
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 |
>> 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.
>> 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).
>> 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
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev