Skip to content

Fix false SyntaxError for named expression as positional argument (f(a := 1, b))#238

Closed
apoorvdarshan wants to merge 1 commit into
davidhalter:masterfrom
apoorvdarshan:fix-walrus-arg-syntaxerror
Closed

Fix false SyntaxError for named expression as positional argument (f(a := 1, b))#238
apoorvdarshan wants to merge 1 commit into
davidhalter:masterfrom
apoorvdarshan:fix-walrus-arg-syntaxerror

Conversation

@apoorvdarshan

Copy link
Copy Markdown

Summary

parso reported a false SyntaxError: positional argument follows keyword argument for valid calls that use a named expression (walrus) as a positional argument, e.g. f(a := 1, b) (issue #212):

>>> import parso
>>> g = parso.load_grammar()
>>> m = g.parse('f(a := 1, b)\n')
>>> [e.message for e in g.iter_errors(m)]
['SyntaxError: positional argument follows keyword argument']   # wrong

CPython accepts f(a := 1, b). The single-argument form f(a := 1) was already accepted, so only the "argument follows" ordering check was affected.

Cause

In _ArglistRule.is_issue (parso/python/errors.py), every argument node that is not */** unpacking and not a comprehension fell into the else: # Is a keyword argument branch. A named expression argument (name := value) has the same top-level node type (argument) as a keyword argument (name = value), so it was misclassified as a keyword argument: it set kw_only = True, which then made any following positional argument raise.

Fix

Detect the := operator (argument.children[1] == ':=') and treat such arguments as positional. They no longer set kw_only. They still correctly raise when a named expression itself follows a keyword argument or keyword-argument unpacking, matching CPython:

Call CPython parso (after fix)
f(a := 1, b) valid valid
f(a := 1, x=2) valid valid
f(b, a := 1) valid valid
f(x=2, a := 1) positional argument follows keyword argument same
f(**x, a := 1) positional argument follows keyword argument unpacking same

Tests / Verification

  • Added valid cases to test_valid_namedexpr in test/test_python_errors.py (f(a := 1, b), f(a := 1, b=2), f(a := 1, *b), f(a := 1, **b), f(b, a := 1), f(*b, a := 1)). The f(a := 1, b) case fails before the fix and passes after.
  • Added the two genuinely invalid orderings (f(x=2, a := 1), f(**x, a := 1)) to test/failing_examples.py, which are cross-checked against the running Python's own error message.
  • Full suite green: 1994 passed.
  • flake8 --extend-ignore F401 parso test/*.py setup.py scripts/ is clean.
  • Added a CHANGELOG.rst entry and my name to AUTHORS.txt.

Fixes #212.

Disclosure: prepared with AI assistance; reviewed and verified locally.

parso raised a false 'SyntaxError: positional argument follows keyword
argument' for valid calls such as f(a := 1, b). A named expression
argument (name := value) was misclassified as a keyword argument because
_ArglistRule treated every non-*/** argument as a keyword, so it set
kw_only and flagged any following positional argument.

Detect the ':=' operator and treat such arguments as positional. They no
longer set kw_only, and they now correctly raise when they themselves
follow a keyword argument or keyword-argument unpacking, matching CPython.

Fixes davidhalter#212.
@davidhalter

Copy link
Copy Markdown
Owner

Hi, I'm sorry to say this, but I decided to not work at all with AI generated pull requests/content. There are multiple reasons for this:

  1. I feel like at this point it's pretty subpar to what a good engineer can create. I have received many AI generated pull requests and they all have massive problems compared to what I received from actual people. People sometimes can't fix the problems they have without AI, but I regard this as a feature: If you don't understand the problem, I don't have to review your code.
  2. I love people. And I would like to interact with all of you; learn from you; teach you. But if you are simply a bridge to an LLM, I'm just wasting my time. I cannot build any form of relationship.
  3. LLMs are the antithesis to what I like about programming. I like the struggle of programming. Of writing code. I love how things come together after a good coding session. This is all missing. And while some form of AI might make that skill useless in the future, it's not useless now and I would really recommend anyone to avoid LLMs for generating complex code.
  4. Even for written English I generally prefer non-LLM text, because it shows something about the person. I understand that some people are incredibly non-fluent, but that's fine. Just do your best and try to learn English. Otherwise we won't have the ability to talk if we ever meet, which would be a pitty.
  5. LLMs are extremely good at generating code/text that looks reasonable. I use them a lot for brainstorming, they are incredible at putting out ideas. They are bad at facts. They are really bad at thinking. The positive thing here is that you have a brain and you can use it to think. Think hard first.
  6. LLMs tend to generate lots of code that is then hard to review. Try to contribute small changes first.

Thank you anyway for trying to contribute to Open Source. I would really appreciate if you avoid the usage of LLMs in my projects. It is obviously fine to use LLMs as a search/brainstorming tool with my projects, just don't use it to interact with me.

PS: As a side note I want to mention that I'm probably not the only maintainer that has a difficult relationship with LLM content. So you probably should ask first before you use LLMs for other repositories.

@davidhalter davidhalter closed this Jul 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Walrus causes unnecessary SyntaxError

2 participants