Hi, On Wed, Oct 20, 2021 at 5:44 PM Michael Selik <m...@quantami.com> wrote:
> On Wed, Oct 20, 2021 at 1:16 AM Piotr Waszkiewicz <waszk...@gmail.com> > wrote: > >> On Wed, Oct 20, 2021 at 2:33 AM Michael Selik <m...@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?
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5K36MMO43TWKAXGGNM257MY356WLZ45M/ Code of Conduct: http://python.org/psf/codeofconduct/
