Introducing a Safe Navigation Operator in Python

[jamesdow21 (James Dow)]

@pf_moore

My point is that we need the proposal to discuss how we make sure that people don’t talk about the new feature in terms of being “like getattr()”, because that’s confusing. And how we stop people thinking that the new operators catch lookup errors. And all of the other ways in which people have misunderstood the proposal in this, and the various previous threads this has been discussed in.

@ncoghlan

Edit: Putting the above another way:

• gettattr(obj, "attr", None) is effectively short for obj.attr if hasattr(obj, "attr") else None
• When obj is known to be a member of a union type SomeTypeThatDefinesAttr|None, then obj.attr if hasattr(obj, "attr") else None has exactly the same effect as obj.attr if obj is not None else None (since the only way for attr to be missing is for obj to be None instead of an instance of SomeTypeThatDefinesAttr)
• as a result, gettattr(obj, "attr", None) is sometimes used as an abbreviation of obj.attr if obj is not None else None when obj is known to be a member of a union type SomeTypeThatDefinesAttr|None (since it avoids repeating the obj expression)

The benefit that PEP 505 offers in that situation is giving people a concise syntax for what they actually mean, so they’re less tempted to reach for an existing concise expression that doesn’t actually mean what they want to express, but is often close enough for practical purposes.

@pf_moore

The disadvantage is that while it’s concise, it’s not as clear. Explicit is better than implicit and all that. Even with the extensive explanation you gave, I still don’t know if the intention of obj?.attr is to return None if obj doesn’t have an attr attribute. Both of the answers “yes” and “no” have featured in various posts in this discussion.

I’ve realized that there is a key part of how I’ve been mentally “framing” and parsing each of these that is actually not stated in the PEP at all (and at a quick skim, the PEP seems to be rejecting outright).

When I’ve been reading obj?.attr, I think of it as obj? .attr not obj ?.attr

i.e. the question that I’m asking in the expression is “Is obj None?”, not “Does obj have attr?”

“Is obj None?” is equivalent to None if obj is None else obj.attr
whereas “Does obj have attr?” is equivalent to getattr(obj, "attr", None)

I have a rudimentary (at best) understanding of parsing grammars, but I think what I actually want is it to be a “unary postfix operator”, but the actual implementation is adding ?. and ?[...] “trailers” for weird grammar reasons that I don’t understand and just assumed must have been the easier way for internal implementation details.

There’s the unary postfix operator section under Rejected Ideas, but it’s mostly about returning a NoneQuestion type that implements dunder methods to return itself, rather than short-circuiting in the expression evaluation grammar.

It’s also addresses the problem of some other combining rules with expressions like:
What should x? + 1 mean?

My answer to that is that I would have it mean:
(None if x is None else x) + 1

Python lets me do that currently, but it’s pretty obvious that it’s risking a TypeError

In [1]: x = 1

In [2]: (None if x is None else x) + 1
Out[2]: 2

In [3]: x = None

In [4]: (None if x is None else x) + 1
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[4], line 1
----> 1 (None if x is None else x) + 1

TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

---

edit: I actually had put a few different times in earlier draft comments (but then removed before posting since it didn’t feel relevant) that I might like to write

engineer = machine.line?.department.engineer?

as a visual indicator that I know line and engineer could be None, and I don’t care that the final ? there is a no-op and could be removed without affecting anything