Me too, but could you provide me an example where try-except approach is more readable when trying to chain attribute lookups (like in the database book-publisher-owner example I have provided before).
I'd echo the others' examples, taking inspiration from PEP 463.
Do you think about something along those lines?
```
phone = book.publisher.owner.phone except AttributeError: None
```
I don't mind this syntax but it would have to be supported by static type checkers and IDEs. And currently something like this is not:
```
try:
phone = book.publisher.owner.phone
except AttributeError:
phone = None
```
mypy complains:
```
error: Item "None" of "Optional[Publisher]" has no attribute "owner"
```
If the motivation for this operator is chained lookups, how about adding a feature to the operator module, first? It seems natural to add a keyword-only argument to `attrgetter`, and it's a lighter touch than implementing a new operator. If use becomes widespread, that gives more weight to PEP 505.
def attrgetter(*attrs, none_aware=False)
https://docs.python.org/3/library/operator.html#operator.attrgetter
I remember using inhouse solution like this at a certain workplace - a method accepting list of string arguments and an object, returning the value being the result of chained attribute access. And it worked all right. The problem I have with such approaches is that the name of the attrs are passed as strings.
I understand the preference for attributes over strings, but many of the none-aware examples use keys and indices. If JSON is the main culprit for deeply nested structures, then you're already using strings and not attributes. Adding features to `operator` wouldn't preclude accepting PEP 505, so why not get started with a less controversial change that provides much of the value?
I have nothing against introducing such a new feature to the `operator` apart from this one problem mentioned before (using strings which are not properly detected by IDE), and I agree that could be a good start.
I've seen chained-attributes-lookups solutions in quite a few places already and I think that there would actually be people benefiting from such addition.
Although I must admit that personally I don't see many benefits of using strings for attribute lookups due to typing and IDE issues mentioned before. Even for JSON data, in my own projects I tend to write dataclasses wrapping parsed dict in order to benefit from IDE tooltips.
If PEP 505 is accepted, it would need support in the `operator` module. Might as well design that aspect of the implementation now.
I'm sorry but I don't know if I understand that sentence correctly. You mean we would have to add an "explicit" function that behaves like a maybe-dot operator?
Is it actually a requirement when adding new operators?