Specialize match syntax error for unary addition in pattern

Feature or enhancement

Proposal:

Consider a specialized syntax error for these cases:

# Unary addition isn't allowed but we parse it for better error recovery.
match subject:
    case +1:
        pass
    case 1 | +2 | -3:
        pass
    case [1, +2, -3]:
        pass
    case Foo(x=+1, y=-2):
        pass
    case {True: +1, False: -2}:
        pass

This was taken from https://github.com/astral-sh/ruff/blob/6ff4da454c448f01eb0b71728f3941870c811bfc/crates/ruff_python_parser/resources/invalid/statements/match/unary_add_usage.py. 2+ years in Ruff's parser.

Current vs proposed:

❯ ./python.exe t.py
  File "/Users/bartosz.slawecki/Python/cpython/t.py", line 2
    case +1:
         ^
-SyntaxError: invalid syntax
+SyntaxError: cannot use unary addition in a literal pattern

The code doesn't look incorrect syntactically, which is why I think it's a good idea to add a more specific message (although it is not extremely unclear as-is assuming a pointer ^ is shown).

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

@sobolevn

cc @sobolevn @Eclips4 @pablogsal

@brandtbucher

CC @brandtbucher

pythongh-145239: Specialize match syntax error for unary addition in …

I've submitted a PR for this: #145658

The approach adds an invalid_literal_pattern rule to the PEG grammar that catches '+' NUMBER and raises the error: "cannot use unary '+' in a literal pattern". This covers all the pattern contexts mentioned in the issue (top-level, alternatives, sequences, class patterns, and mapping patterns).

This contribution was developed with AI assistance (Claude Code).

Should we accept + instead?
ast.literal_eval allows it. Also, 3e+1 is a valid spelling for 3e1 (using a different mechanism of course).

Personally, I'd love to be able to write:

match direction:
    case 0, +1: go_up()
    case 0, -1: go_down()
    case -1, 0: go_left()
    case +1, 0: go_right()

@encukou

@encukou yeah, +1 (no pun intended). I'd love to see it supported and actually started implementing that locally. Do you think I should open a DPO? Is it minor enough to not need a PEP?

I'd wait a day or two in case a parser expert wants to veto the idea here :)

@pablogsal

cc @pablogsal

pythongh-145239: Accept unary plus in match literal patterns

pythongh-145239: Add tests for unary plus in match literal patterns

pythongh-145239: Add NEWS entry

gh-145239: Accept unary plus literal pattern (#148566)

pythongh-145239: Accept unary plus literal pattern (python#148566)

gh-145239: Colorize `case +` in the REPL (#150979)

pythongh-145239: Colorize `case +` in the REPL (python#150979)

Navigation Menu

Repository navigation

Specialize `match` syntax error for unary addition in pattern #145239

Feature or enhancement

Proposal:

Has this already been discussed elsewhere?

Links to previous discussion of this feature:

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Specialize match syntax error for unary addition in pattern #145239

Description

Feature or enhancement

Proposal:

Has this already been discussed elsewhere?

Links to previous discussion of this feature:

Linked PRs

Activity

johnslavik commented on Feb 26, 2026

pablogsal commented on Feb 26, 2026

mvanhorn commented on Mar 9, 2026

encukou commented on Mar 10, 2026

johnslavik commented on Mar 10, 2026

encukou commented on Mar 10, 2026

johnslavik commented on Mar 10, 2026

khalidsaidi commented on Mar 25, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Specialize `match` syntax error for unary addition in pattern #145239