To the contrary. I read and write code that performs explicit checks
for None all the time. Catching AttributeError is often a code smell
or at least a measure of last resort.
On Sat, Sep 10, 2016 at 6:46 PM, David Mertz
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 Sep 10, 2016 6:29 PM, "MRAB"
wrote: 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.)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)