On Wed, Oct 20, 2021 at 9:39 PM Michael Selik <m...@quantami.com> wrote:
> > > On Wed, Oct 20, 2021 at 9:18 AM Piotr Waszkiewicz <waszk...@gmail.com> > wrote: > >> Do you think about something along those lines? >> ``` >> phone = book.publisher.owner.phone except AttributeError: None >> ``` >> > > Yes, that seems reasonable. > Nice, I think I would also be able to get used to that notation. It's good to know that there are others supporting the PEP 463, maybe it'd be possible to propose it once again. > > >> 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" >> ``` >> > > That sounds like a feature request for mypy. Would creating a new operator > make it easier to implement analysis of that situation would mypy? My guess > is not. Checking the AST to see if there's a try/except AttributeError > sounds comparable to checking for the use of a none-aware operator. I'm > completely ignorant of how mypy does its analysis, so that's just a wild > guess. > I'm not sure, just wanting to point out that the `AttributeError` syntax is not completely equivalent to the maybe-dot operator here. This example would actually hide a real AttributeError problem, e.g. if the `publisher` didn't have an owner field. So I guess there may be a need to introduce a new exception type, e.g. `NoneAttributeAccess` before mypy can safely allow any attribute access in such situation. > > 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? >> > > The documentation of the `operator` module says, "The operator module > exports a set of efficient functions corresponding to the intrinsic > operators of Python." It feels like there's an implicit "all" in there. The > table of correspondences looks exhaustive. I haven't noticed any exceptions. > > > https://docs.python.org/3/library/operator.html#mapping-operators-to-functions > Thank you very much, I wasn't aware of that module before. Will look into that. I don't want to prolong this conversation too much, as I feel like I get your point and agree with it to some (rather great) extent. That doesn't change my attitude towards this PEP 505 proposal though, as I feel that if the general consensus would be towards accepting this change it will bring some quality of life improvements in a usual day-to-day work, when dealing with not-so-ideal code. I'd be also interested in seeing PEP 463 being resurrected as it looks like there are some folks here interested in restarting the discussion about it. Thank you very much for the fruitful discussion and broadening my knowledge.
_______________________________________________ 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/IO5SREDWU3TJFEEXZ4ULD6D7PTGL4MNE/ Code of Conduct: http://python.org/psf/codeofconduct/
