Hi, On Wed, Oct 20, 2021 at 5:44 PM Michael Selik <mike@quantami.com> wrote:
On Wed, Oct 20, 2021 at 1:16 AM Piotr Waszkiewicz <waszka23@gmail.com> wrote:
On Wed, Oct 20, 2021 at 2:33 AM Michael Selik <mike@quantami.com> wrote:
In case it saves anyone a couple clicks: https://www.python.org/dev/peps/pep-0463/ I also prefer more syntactic help with exceptions, rather than more syntax emphasizing None's uniqueness.
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?