Repository navigation
ast.parse creates only Constant(value=0) nodes for a case +0: pattern, which is inconsistent. #152708
Description
Bug report
Bug description:
I found the following asymmetry in the generated ast while I was working with the new cpython 3.15.
c="""
match 0:
case +0:
pass
case -0:
pass
+0
-0
"""
import ast
print(ast.dump(ast.parse(c),indent=2))output (Python 3.15.0b3+dev):
Module(
body=[
Match(
subject=Constant(value=0),
cases=[
match_case(
pattern=MatchValue(
value=Constant(value=0)),
body=[
Pass()]),
match_case(
pattern=MatchValue(
value=UnaryOp(
op=USub(),
operand=Constant(value=0))),
body=[
Pass()])]),
Expr(
value=UnaryOp(
op=UAdd(),
operand=Constant(value=0))),
Expr(
value=UnaryOp(
op=USub(),
operand=Constant(value=0)))])+0 is parsed to Constant(value=0) instead of UnaryOp(op=UAdd(),operand=Constant(value=0)) when it is used as a match-expression.
This was really unexpected for me and can maybe produce some problems with ast.parse/unparse roundtripps or code which works with the ast and require workarounds (like in my case)
Is it possible to implement this in a way that it generates UnaryOp(...)?
@johnslavik you implemented this #148566, maybe you can help me here.
CPython versions tested on:
3.15
Operating systems tested on:
No response
Activity
Twix1288 commentedon Jun 30, 2026
I would love to look at this bug to fix
Add NEWS entry for pythongh-152708
gh-152708: Fix AST generation asymmetry for unary positive in match s…
[3.15] gh-152708: Fix AST generation asymmetry for unary positive in …
test: python/cpython#152708 is merged and part of 0.15.0.rc3
test: python/cpython#152708 is merged and part of 0.15.0.rc3
3.15 support (#109)