PEP 823: None-aware access operators#4798

cdce8p

Basic requirements (all PEP Types)

Read and followed PEP 1 & PEP 12
File created from the latest PEP template
PEP has next available number, & set in filename (pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) and PEP header
Title clearly, accurately and concisely describes the content in 79 characters or less
Core dev/PEP editor listed as Author or Sponsor, and formally confirmed their approval
Author, Status (Draft), Type and Created headers filled out correctly
PEP-Delegate, Topic, Requires and Replaces headers completed if appropriate
Required sections included
- Abstract (first section)
- Copyright (last section; exact wording from template required)
Code is well-formatted (PEP 7/PEP 8) and is in code blocks, with the right lexer names if non-Python
PEP builds with no warnings, pre-commit checks pass and content displays as intended in the rendered HTML
Authors/sponsor added to .github/CODEOWNERS for the PEP

Standards Track requirements

PEP topic discussed in a suitable venue with general agreement that a PEP is appropriate
Suggested sections included (unless not applicable)
- Motivation
- Specification
- Rationale
- Backwards Compatibility
- Security Implications
- How to Teach This
- Reference Implementation
- Rejected Ideas
- Open Issues
- Acknowledgements
- Footnotes
- Change History
Python-Version set to valid (pre-beta) future Python version, if relevant
Any project stated in the PEP as supporting/endorsing/benefiting from the PEP formally confirmed such
Right before or after initial merging, PEP discussion thread created and linked to in Discussions-To and Post-History

📚 Documentation preview 📚: https://pep-previews--4798.org.readthedocs.build/

hugovk

@gvanrossum Please can you confirm you're sponsoring this PEP?

gvanrossum

@gvanrossum Please can you confirm you're sponsoring this PEP?

Yes.

gvanrossum

Here are a ton of nits. I am strongly in favor of this proposal -- I just think the main exposition is a bit unwieldy. Thanks for writing this Marc!

Note that I didn't get to the Deferred/Rejected ideas yet. Some of the things I balk over in the main exposition (like using the walrus or match/case) might find a place in the latter.

Nice -- this matches exactly what Optional[X] means in the type notation.

Suggested change

      
                keys when they are not preset.
          
                keys without a default.

I could be missing something, but I think TypedDicts don't have any default values. Keys can either be present or absent.

"without a default" would apply to dataclasses.

Then what does "without a preset" mean?

Honestly this example is overly complex (five classes before you get to the point!) and quite unrealistic. I also don't understand what real-world scenario this represents (what is the relationship between Sensor and Machine; and what is a Line?).

I think it would be sufficient to show the semantics of a?.b?.c, which is

None if a is None else b?.c

which expands to

None if a is None else (None if (_t := a.b) is None else _t.c

Combining this with ?[ ] is inherently complicated because this is much less common. It would be sufficient to add a phrase like "and similar for a?[b]?[c] or a?[b]?.c or a?.b?[c]".

Finally, I would never write such code that way -- I'd probably use a bunch of nested or serial if-statements, for readability.

Honestly the first version of the code should just compare to None everywhere, so you won't have to write this paragraph and the next plus the refined example (or you can just start with the latter). We don't need to have a whole treatise about coding style in this PEP. And honestly, except in the case of objects that behave like a container (like lists), an object evaluating to None is an anti-pattern where I'm concerned.

What about (a?.b) = 1 ??? It should fail, but the text here does not say so explicitly, I think.

That will fail. Similar to (None) = 1 and (True) = 1. The t_primary grammar rule isn't changed.

Will see if I can point that out more clearly.

The latter fail during parsing, with a SyntaxError. Will (a?.b) = 1 also be a SyntaxError? I think it can be.

It already is. It's actually the same even the same error message as for (None) = 1 since it's triggered in the same code path during parsing.

>>> a = None
>>> (a?.b) = 1
  File "<python-input-1>", line 1
    (a?.b) = 1
     ^^^^
SyntaxError: cannot assign to none aware expression here. Maybe you meant '==' instead of '='?

I just updated both PEPs to fix the links to the reference implementations and the (shared) demo. Feel free to try it out yourself: https://pep823-and-pep824-demo.pages.dev/

Honestly I'd only teach them ?. and wait until they ask if there's an equivalent for [ ] before telling them that.

cdce8p

Thanks for the detailed feedback! I'd like to address your general comments regarding the motivation section here directly instead of splitting it up for each comment.

While I was preparing to write this PEP, I reread a lot of the discussions from the last few years. One of the most common arguments against these operators was that they are basically just syntactic sugar and don't add anything new. Technically speaking this is correct. We both know that these would still be great additions and make certain coding patterns a lot easier to write. However, the question I asked myself was how can I best explain why all the other patterns are only suboptimal.

I ended up with the structure you read. It starts at "beginner" level with simple truthiness checks. I've actually seen code like this in production. Sometimes lazy code is enough even if it contains problems. It continues with the explicit is not None checks, before ultimately adding the assignment expressions as well. try and match were added as these were the other often suggested builtin alternatives.

By showcasing how each of these work, I can point out the subtle issues each option has and provide a justification why ?. and ?[ ] should be added.

In the end I also wanted to avoid falling into the same, IMO trap, PEP 505 did with just showing nice examples and basically saying the new operators are just better. https://peps.python.org/pep-0505/#examples That's also why I deliberately moved the common patterns towards the end of the motivation section.

--
I admit the example isn't ideal. It's adopted from a discussion post I saw. However, I wanted to add some "real" class and variable names for these examples. Of course, a?.b.c?[d].e would work as well, but that oftentimes seems contrived and far away. PEP 505 did that and I always found that somewhat unintuitive, even though it's strait forward. https://peps.python.org/pep-0505/#the-maybe-dot-and-maybe-subscript-operators

I'm happy to change it if we can come up with a better example.

Do you point out somewhere that effectively this is equivalent to (a?.b)?.c.d

Only implicitly in the grouping section.

because that's an easy-to-remember way to recall the relative priority of multiple ? operators in the same primary expression.

I'm not sure priority is a good concept here. The expressions are evaluated left to right like it's the case with "normal" access operators. Each is effectively evaluated on its own, one after the other. Tbh I tried to avoid adding grouping to the examples as much as possible, aside from the dedicated section. I feel like thinking about them just complicates things unnecessarily.

I'll think about this some more if it makes sense to point out somewhere.

That will fail. Similar to (None) = 1 and (True) = 1. The t_primary grammar rule isn't changed.

Will see if I can point that out more clearly.

Technically both (?) though it's really just the three changes listed below

Added NoneAwareAttribute node
Added NoneAwareSubscript node
Added group attribute for all expression nodes.

gvanrossum

I'd like to address your general comments regarding the motivation section here directly instead of splitting it up for each comment.

You're right to push back -- am taking a pretty extreme POV here.

About syntactic sugar: half of Python is syntactic sugar. We don't need for, we can do everything with while. We don't need or / and, we can do that with if. Etc. (Brett Cannon has a blog series about how far you can take this.) So the argument against the PEP from "it's just syntactic sugar" isn't very strong.

My main feeling about the long exposition in the Motivation section is that many of the things you show are either just bad habits (no matter how often people write them -- this PEP isn't the place to educate them), or straw-men examples that look like they are only shown to shoot them down (the match/case version). If people have brought these up in the discussion and you want to capture that, maybe you can move them to the "Rejected ideas" section with subheadings like "Do nothing -- use match/case (or try/except, or whatever other suggestion was made)".

How do you feel about that option? If you don't like that either, I'll approve your current approach -- I don't want to die on this hill. :-)

cdce8p

How do you feel about that option? If you don't like that either, I'll approve your current approach -- I don't want to die on this hill. :-)

I'll think about this some more. You might not have gotten around to it yet but I do also have added a Common objections section with Just use ... subsections towards the end which similarly captures some of the ideas. Maybe I can come up with a good way to combine them.

What does name refer to? If you're thinking of .name, that's already covered by "attribute access". If you're thinking of name?.b.c, name is never skipped.

hugovk

Just a note that this PEP (and #4799) is targeting Python 3.15 and the feature freeze is a couple of months away.

And these PRs will need to be merged, discussed/revised, submitted to the SC, approved, and implemented before then if they're to make 3.15, so there's not a huge amount of time.

cdce8p

Just a note that this PEP (and #4799) is targeting Python 3.15 and the feature freeze is a couple of months away.

Thanks for the reminder @hugovk. I was thinking about how to rewrite the motivation section based on the feedback but then life happened. I do plan to finish things up for the next round of reviews within the next few days, hopefully this weekend.

I'm aware that the time until the feature freeze is quite short. Thankfully the technical questions are AFAIK settled now after the intense prior discussions the last few months. Though of course there is always the possibility that something else comes up after these two have been posted.

PEP 823: None-aware access operators

663efa8

cdce8p requested a review from a team as a code owner January 31, 2026 17:06

cdce8p marked this pull request as draft January 31, 2026 17:06

hugovk mentioned this pull request Jan 31, 2026

PEP 824: Coalescing operators #4799

Draft

30 tasks

Fix typos

56a58b5

cdce8p mentioned this pull request Jan 31, 2026

PEP XXX: None-aware access operators [DRAFT] cdce8p/python-peps#1

Closed

gvanrossum reviewed Jan 31, 2026

View reviewed changes

cdce8p commented Feb 1, 2026

View reviewed changes

Minor changes

732a99b

gvanrossum reviewed Feb 1, 2026

View reviewed changes

Add links to reference implementation and demo

52ec427

brianschubert added the new-pep A new draft PEP submitted for initial review label Feb 23, 2026

Merge branch 'main' into pep823-none-aware-access-operators

4cee064

hugovk reviewed May 7, 2026

View reviewed changes

Comment thread peps/pep-0823.rst Outdated Show resolved Hide resolved

Move pep-0823.rst to 3.16 …

5ea0ea8

Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

+              An attribute or value is ``missing``
+                  An attribute or value is considered ``missing`` if it is not present
+                  at all. For ``typing.TypedDict`` these would be ``typing.NotRequired``
+                  keys when they are not preset.

+              some point, the function would just return ``None``. This is problematic
+              since ``None`` is a valid return value already. Thus this would not raise
+              an exception in the caller and even type checkers would not be able to
+              detect it. The solution here is to compare with ``None`` instead.

+              An attribute or value is ``optional``
+                  In the context of this PEP an attribute or value is considered
+                  ``optional`` if it is always present but can be ``None``.

+                  class Person:
+                      emails: list[str] | None
+                  def get_person_email(sensor: Sensor) -> str | None:

+              After students know how the attribute access ``.`` and subscript ``[ ]``
+              operators work, they may learn about the "``None``-aware" versions for
+              both.

+                  # a.b?.c()
+                  _t.c() if ((_t := a.b) is not None) else None
+                  # a?.b?.c.d

+              at runtime otherwise a ``TypeError`` is raised. This behavior is similar
+              to awaiting any other variable which can be ``None``.
+              AST changes

+                  None
+              The ``None``-aware access operators will only short-circuit expressions
+              containing name, attribute access, subscript, their ``None``-aware

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

PEP 823: None-aware access operators#4798