Zero Piraeus writes:
If I write something like obj.attr, the failure mode I care about is that obj has no attribute attr, rather than that obj is specifically None (or one of a defined group of somewhat Nonelike objects).
Clearly, in such a circumstance, obj is not what I expected it to be, because I thought it was going to have an attribute attr, and it doesn't.
That's what you care about because you're working with a data model where obj should not be None, and so you want an AttributeError to be raised when your assumption is violated. That's fine.
But other people have other needs. PEP-505 includes a script that detects examples of null-coalescing and safe navigation syntax so that we can run it on real projects. Rather than debating if None should be used in this way, I prefer to measure how frequently None is already being used this way.
I'm sure it's obvious by now that I think the intuitive behaviour of any
?. operator is to suppress AttributeError on the right hand side, rather than check for nullity on the left.
I can't emphasize strongly enough (and the same is said in PEP-505): this is not an error handling syntax. It does not suppress any exceptions. It is a syntax for handling common patterns with None. These are patterns that demonstrably exist in real Python code, including the standard library. Rewriting that code to use this new syntax would not change the safety, semantics, or error handling of that code.
However, I do think an alternative is possible: extend getattr().
getattr(obj, ('chain', 'of', 'attributes'), default)
This is more verbose than an operator, but I think its intent is clearer, and its verbosity makes it less likely to be misused.
How do your proposed built-in handle this case?
Incidentally, Chris Angelico's PEP 463 "Exception-catching expressions"
could result in a clearer-still idiom:
(obj.chain.of.attributes except AttributeError: default)
... but I suppose that ship has sailed.
That doesn't have the same semantics as obj?.chain.of.attributes. If you haven't read the PEP, all of these issues are covered in great detail.