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.
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?
If PEP 505 is accepted, it would need support in the `operator` module. Might as well design that aspect of the implementation now.