[issue32012] Disallow ambiguous syntax f(x for x in [1],)

miss-islington added the comment: New changeset 9ecbe3321f7bb3726017a053e583ca507d4453fc by Miss Islington (bot) in branch '3.7': Revert "closes bpo-27494: Fix 2to3 handling of trailing comma after a generator expression (GH-3771)" (GH-8241)

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Change by miss-islington : -- pull_requests: +8089 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Serhiy Storchaka added the comment: New changeset 4b8a7f51da224d1a0ad8159935f78ba4e6e16037 by Serhiy Storchaka in branch 'master': Revert "closes bpo-27494: Fix 2to3 handling of trailing comma after a generator expression (GH-3771)" (#8241)

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Nick Coghlan added the comment: With issue 32023 (base class lists) and 32034 (fixing the documentation for decorator factory function calls) covering the other refinements, this particular issue is done now. The most recent PR is the one for issue 32023. --

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Change by Serhiy Storchaka : -- pull_requests: +4348 ___ Python tracker ___ ___

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Serhiy Storchaka added the comment: New changeset 9165f77d5f93a2c12aa0e90853e3ae7212800d3c by Serhiy Storchaka in branch 'master': bpo-32012: Disallow trailing comma after genexpr without parenthesis. (#4382)

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Guido van Rossum added the comment: It's a (small) mistake that we didn't make the syntax for argument lists in decorators the same as argument lists everywhere else, and that should be fixed to allow exactly what's allowed in regular calls. (That syntax is weird because we

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Change by Yury Selivanov : -- nosy: -yselivanov ___ Python tracker ___ ___

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Change by Stefan Krah : -- nosy: -skrah ___ Python tracker ___ ___ Python-bugs-list

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Stefan Krah added the comment: Yes Sir! -- nosy: +skrah ___ Python tracker ___ ___

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Serhiy Storchaka added the comment: Stefan, `[1,2,3]` is an expression, but `x for x in [1,2,3]` is not. If you want to change the Python language specification, please open a topic on Python-Dev and provide the rationale. --

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Change by Stefan Krah : -- nosy: -skrah ___ Python tracker ___ ___ Python-bugs-list

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Serhiy Storchaka added the comment: I would prefer to fix all related cases in one issue, for having all examples in one place and having only one reference. All this cases are caused by the limitation of the parser used in CPython, and using different grammar

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Stefan Krah added the comment: On Tue, Nov 14, 2017 at 01:31:52PM +, Nick Coghlan wrote: > If limited to the original scope, this isn't a new special case, it's fixing > a bug in the implementation of the existing special case (where it's ignoring > the trailing comma

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Nick Coghlan added the comment: If limited to the original scope, this isn't a new special case, it's fixing a bug in the implementation of the existing special case (where it's ignoring the trailing comma when it shouldn't be). If it hadn't been for the scope creep to

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Stefan Krah added the comment: I would prefer to do nothing about the subject of this issue. I still don't see any ambiguity, except in a very broad colloquial sense. Why introduce another special case? -- ___ Python tracker

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Nick Coghlan added the comment: OK, I've filed https://bugs.python.org/issue32024 to cover the decorator syntax discrepancy. So I'd still prefer to restrict the patch for *this* issue to just the genuinely ambiguous case, and leave the

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Stefan Krah added the comment: I think "ambiguous" is not the right word. If a single argument can be a non-parenthesized generator and all arguments can be followed by a trailing comma, it's clear. The language spec is often behind in my experience. -- nosy:

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Henk-Jaap Wagenaar added the comment: I think this showcases how difficult it is to get this right, requires carefully reading the EBNF language spec, not just the text, and the behaviour is unexpected. -- ___ Python

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Serhiy Storchaka added the comment: No, it doesn't match the "@dotted_name(arg_list)" pattern. decorator: "@" `dotted_name` ["(" [`argument_list` [","]] ")"] NEWLINE call: `primary` "(" [`argument_list` [","] | `comprehension`] ")" argument_list:

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Nick Coghlan added the comment: I created https://bugs.python.org/issue32023 to explicitly cover the base class list case, and after checking the language spec, I agree that case should be a syntax error. However, `@deco(x for x in [])` should *not* be a syntax error, as:

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Serhiy Storchaka added the comment: The problem with these constructions is that they are not allowed by the Python language specification. It should be explicitly changed for allowing them. And this change should be accepted by Guido. -- nosy:

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Nick Coghlan added the comment: In a function call, `f(x for x in iterable)` is roughly equivalent to `f(iter(iterable))`, not `f(*iterable)` (the genexp based equivalent of the latter would be ``f(*(x for x in iterable))`). Thus the base class list is no different from

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Serhiy Storchaka added the comment: I think this issue is not the best way for answering your question, but I will make a try. The fact that "class C(x for x in [object]): ..." does not cause a syntax error is a bug. This issue fixes it. The fact that corrected

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Henk-Jaap Wagenaar added the comment: [As a follow-on, should I open a new issue/discuss on python-dev? Willing to help out with a solution on way or another! I know https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence, "In my head" <> "Should be the case"

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Henk-Jaap Wagenaar added the comment: Currently, Class C(*some_classes): ... works 'as expected' and is within grammar and language specification whereas Class C(x for x in [object]): ... does not work but does not cause a syntax error. I can see a use

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Serhiy Storchaka added the comment: It is easy to forbid the above cases, but I don't know what error message is appropriate. General "invalid syntax"? -- ___ Python tracker

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Serhiy Storchaka added the comment: PR 4382 doesn't change the grammar, it changes only checks in the CST to AST transformer. Maybe it would be better to change the grammar. Currently it doesn't match the language specification and allows the following

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +4330 stage: -> patch review ___ Python tracker ___

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

New submission from Serhiy Storchaka : The syntax f(x for x in [1],) is ambiguous and reasons that allow it (omitting parenthesis in generator expression and using trailing comma in call expression) are not applicable in this case. Rationales see on Python-Dev: