On 09/12/2016 02:13 PM, Paul Moore wrote:
On 12 September 2016 at 21:47, Eric Snow wrote:
Note that there's a subtle difference here when multiple lookups are
involved. Given:
def f(spam):
return spam().eggs().ham
With null-coalescing:
def f(spam):
return spam()?.eggs()?.ham
This is roughly equivalent to:
def f(spam):
_spam = spam()
try:
eggs = _spam.eggs
except AttributeError:
return None
_eggs = eggs()
try:
return _eggs.ham
except AttributeError:
return None
From previous explanations in this thread, that's *not* the behaviour at all.
If I understand the proposal, f is actually intended to be equivalent to:
def f(spam):
spam_val = spam()
if spam_val is None:
return None
eggs_val = spam_val.eggs()
if eggs_val is None:
return None
return eggs_val.ham
Personally, I find it pretty worrying that there's this persistent
confusion over what the proposed syntax means. Sure, it's explained in
the PEP and proposal, but if it gets implemented it'll be in the docs.
And yet people don't seem to read any of those - and their intuition
of what the construct does is wrong.
IMO, the syntax may well be useful, but if we don't address the
problem that what people *think* it means isn't what it actually
means, then it'll do more harm than good.
Perhaps the bumper-sticker explanation is:
None-coalescing is not to /recover/ from an AttributeError, but to _prevent it_
in the first place -- but only when the base object is already None.
Okay, several bumper stickers. ;)
--
~Ethan~
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/