PEP 823: None-aware access operators #4798

cdce8p · 2026-01-31T17:06:26Z

Basic requirements (all PEP Types)

Standards Track requirements

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

hugovk · 2026-01-31T17:48:52Z

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

gvanrossum · 2026-01-31T18:31:42Z

@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.

peps/pep-0823.rst

gvanrossum · 2026-01-31T19:04:59Z

peps/pep-0823.rst

+
+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``.


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

gvanrossum · 2026-01-31T19:06:03Z

peps/pep-0823.rst

+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.


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?

gvanrossum · 2026-01-31T19:18:12Z

peps/pep-0823.rst

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


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.

gvanrossum · 2026-01-31T19:33:55Z

peps/pep-0823.rst

+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.


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.

gvanrossum · 2026-01-31T22:10:00Z

peps/pep-0823.rst

+        ^^^^
+    SyntaxError: cannot assign to none aware expression
+
+It is however possible to use them in `groups <Grouping>`_, though care


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/

peps/pep-0823.rst

gvanrossum · 2026-01-31T22:15:12Z

peps/pep-0823.rst

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


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

peps/pep-0823.rst

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.

cdce8p · 2026-01-31T23:56:16Z

peps/pep-0823.rst

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


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.

cdce8p · 2026-02-01T00:08:56Z

peps/pep-0823.rst

+        ^^^^
+    SyntaxError: cannot assign to none aware expression
+
+It is however possible to use them in `groups <Grouping>`_, though care


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.

cdce8p · 2026-02-01T00:12:14Z

peps/pep-0823.rst

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


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.

peps/pep-0823.rst

gvanrossum · 2026-02-01T22:14:16Z

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 · 2026-02-01T22:22:04Z

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.

gvanrossum · 2026-02-01T22:31:23Z

peps/pep-0823.rst

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


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.

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

27 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

Uh oh!

PEP 823: None-aware access operators #4798

Are you sure you want to change the base?

PEP 823: None-aware access operators #4798

Conversation

cdce8p commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Basic requirements (all PEP Types)

Standards Track requirements

Uh oh!

hugovk commented Jan 31, 2026

Uh oh!

gvanrossum commented Jan 31, 2026

Uh oh!

gvanrossum left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cdce8p left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

gvanrossum commented Feb 1, 2026

Uh oh!

cdce8p commented Feb 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

cdce8p commented Jan 31, 2026 •

edited

Loading