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/

Reply via email to