Ok, I have been thinking of the behavior too broadly. I realize now that `x?.foo` might still simply raise an AttributeError if x is neither None nor a thing with a foo attribute.
The class I wrote is definitely too aggressive for the behavior described. On the other hand, by being narrower in behavior there feels like even less motivation for new syntax.
On 2016-09-11 02:02, David Mertz wrote:
On Sat, Sep 10, 2016 at 5:23 PM, Guido van Rossum <guido@python.orgx?.foo would lookup attribute 'foo' _unless_ x was None, in which case it would return None. It's simply:
<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).
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.)
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/