On 2016-09-11 02:02, David Mertz wrote:
On Sat, Sep 10, 2016 at 5:23 PM, Guido van Rossum
mailto:guido@python.org> wrote: No. PEP 505 actually solves the problem without ever catching AttributeError. Please read it.
I read it again (I did a year ago, but reviewed it now). I hadn't been thinking that the *mechanism* of a new None-coalescing operator would actually be catching an exception. It could (and should) work differently if it becomes syntax.
What I was getting at with "essentially" was that it would *do the same thing* that an AttributeError does. That is, if `x.foo` can't be evaluated (i.e. x doesn't have an attribute 'foo'), then access is informally "an error." The hypothetical "x?.foo" catches that "error" and substitutes a different value. The particular implementation under-the-hood is less important for most programmers who might use the construct (and I think documentation would actually give an informal equivalent as something similar to what I put in the NoneCoalesce class).
x?.foo would lookup attribute 'foo' _unless_ x was None, in which case it would return None. It's simply: None if x is None else x.foo This means that None?.__str__() would return None, not 'None'. (None has an attribute called '__str__', and None.__str__() returns 'None', but it would not be looked up because None is, well, None.)