[Python-ideas] Null coalescing operators

[Guido van Rossum]

On Mon, Sep 21, 2015 at 2:23 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> Add me to the detractors of what I have read so far ;-).
>
> In arithmetic, 1/0 and 0/0 both stop the calculation.  My hand calculator
> literally freezes until I hit 'on' or 'all clear'.  Early computers also
> stopped, maybe with an instruction address and core dump.  Three orthogonal
> solutions are: test y before x/y, so one can do something else; introduce
> catchable exceptions, so one can do something else; introduce contagious
> special objects ('inf' and 'nan'), which at some point can be tested for,
> so one can do something else.  Python introduced 'inf' and 'nan' but did
> not use them to replace ZeroDivisionError.
>
> Some languages lacking exceptions introduce a contagious null object. Call
> it Bottom.  Any operation on Bottom yields Bottom.  Python is not such a
> language. None is anti-contagious; most operations raise an exception.
>
> I agree with Paul Moore that propagating None is generally a bad idea. It
> merely avoids the inevitable exception.  Or is it inevitable? Trying to
> avoid exceptions naturally leads to the hypergeneralization of allowing '?'
> everywhere.
>
> Instead of trying to turn None into Bottom, I think a better solution
> would be a new, contagious, singleton Bottom object with every possible
> special method, all returning Bottom. Anyone could write such for their one
> use.  Someone could put it on pypi to see if there how useful it would be.
>

I think this is the PyMaybe solution. What I don't like about it is that it
is dynamic -- when used incorrectly (or even correctly?) Bottom could end
up being passed into code that doesn't expect it. That's bad -- "if x is
None" returns False when x is Bottom, so code that isn't prepared for
Bottom may well misbehave. In contrast, PEP 505 only affects code that is
lexically near the ? operator.

(You may see a trend here. PEP 498 is also carefully designed to be
locally-scoped.)


> I agree with Ron Adam that the narrow issue is that bool(x) is False is
> sometimes too broad and people dislike of spelling out 'x is not None'. So
> abbreviate that with a unary operator; 'is not None', is a property of
> objects, not operators. I think 'x!' or 'x?', either meaning 'x is not
> None', might be better than a new binary operator. The former, x!, re-uses
> ! in something close to its normal meaning: x really exists.


I don't think the big issue is bool(x) being too broad. That's what the
binary ?? operator is trying to fix, but to me the more useful operators
are x?.y and x?[y], both of which would still require repetition of the
part on the left when spelled using ??.

This is important when x is a more complex expression that is either
expensive or has a side-effect. E.g. d.get(key)?.upper() would currently
have to be spelled as (some variant of) "None if d.get(key) is None else
d.get(key).upper()" and the ?? operator doesn't really help for the
repetition -- it would still be "d.get(key) ?? d.get(key).upper()".

In general to avoid this repetition you have to introduce a local variable,
but that's often awkward and interrupts the programmer's "flow". The ?
solves that nicely. The key issue with this proposal to me is how it
affects readability of code that uses it, given that there isn't much
uniformity across languages in what ? means -- it could be part of a method
name indicating a Boolean return value (Ruby) or a conditional operator (C
and most of its descendents) or some kind of shortcut.

So this is the issue I have to deal with (and thought I had dealt with by
prematurely rejecting the PEP, but I've had a change of heart and am now
waiting for the PEP to be finished).

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150921/bf3e1042/attachment.html>