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 NoneFrom 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 [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
