[Python-ideas] Fwd: Null coalescing operator

[Ethan Furman]

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~