gh-155087: Add ternary conditional operator (?:) and $-prefix None-declaration syntax

[RAJ0793]

What does this PR do?

Adds two new pieces of syntax to CPython's grammar as a proof-of-concept:

1. $name — declares a variable pre-initialized to None:

   $a
   print(a)   # None

2. Ternary conditional operator ?: (C-style), including support for
   assignment-aware branches via NamedExpr reuse:

   x = 12 > 2 ? 5 : 4
   a = cond ? (c := 5) : (d := 6)

Related issue

Related issue

See discussion in gh-155087

Motivation

Python's existing x if cond else y covers the same use case as ?:, and
this PR is intended primarily as a working reference implementation to
support the discussion in the linked issue, not as a claim that this should
be merged as-is. I wanted to validate the feasibility (grammar, parser,
codegen) before further discussion.

What's implemented

• Grammar rule for $name in Grammar/python.gram (dollar_stmt)
• Grammar rule for ?: (question_if_expression), integrated into
  expression and expression_without_invalid so it works consistently
  across statements, comprehensions, generator expressions, lambdas, and
  keyword arguments
• Assignment-aware ternary branches reuse the existing NamedExpr (:=)
  AST node rather than introducing a new ASDL node, since := already
  provides "assign and yield that value" semantics

Known limitations

• Ternary inside f-strings (f"{cond ? a : b}") currently fails without
  parentheses — this is because fstring_replacement_field uses
  annotated_rhs in a context where the f-string's own tokenizer appears
  to conflict with the ?/: tokens. This needs further investigation
  and is not yet fixed in this PR.
• No PEP has been written for this; I'm opening this PR primarily to make
  the reference implementation available for discussion, per feedback in
  the linked issue.

Testing done

Manually tested (no automated test suite added yet):

• Operator precedence with arithmetic/boolean operators
• Nested ternaries
• List/dict/set comprehensions, generator expressions
• Lambda, walrus operator, keyword arguments
• Confirmed existing if/else ternary and other syntax remain unaffected

Checklist

• I have read the CPython Developer's Guide
• This is a proof-of-concept / discussion PR, not claiming production-readiness
• No PEP has been submitted for this syntax change yet — feedback on
  whether one is needed is welcome

[python-cla-bot]

The following commit authors need to sign the Contributor License Agreement:

• rajdeepdeyon2022@gmail.com
• rajdeepdeyon2025@outlook.com

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #33876269 | 📁 Comparing 4e3560f against main (04a1fcf)

  🔍 Preview build  

2 files changed

± library/token.html
± reference/grammar.html

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4e3560f096

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Gate the new syntax by feature_version

When callers parse with an older grammar via PyCF_ONLY_AST/ast.parse(..., feature_version=(3, 15)), this rule still accepts a ? b : c because it constructs IfExp directly instead of using CHECK_VERSION. Since this tree is already Python 3.16 (PY_MINOR_VERSION is 16), the new ?: syntax (and the new $ statement rule) should be wrapped in a version check so tools that request an older grammar continue to reject it.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Use LF endings for regenerated files

This regenerated file was written with CRLF line endings, and the same happened to many generated C/Python files in the patch; git diff --check e56405d^ e56405d reports these added lines as trailing whitespace. That will make whitespace/patch checks fail even though the semantic token changes are small, so these files should be regenerated or normalized with LF endings before landing.

Useful? React with 👍 / 👎.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[picnixz]

Large feature requests must be discussed and require a PEP. Do not suggest such changes in the future please.