[Python-ideas] PEP 531: Existence checking operators

[Steven D'Aprano]

On Fri, Oct 28, 2016 at 06:30:05PM +1000, Nick Coghlan wrote:

[...]
> 1. Do we collectively agree that "existence checking" is a useful
> general concept that exists in software development and is distinct
> from the concept of "truth checking"?

Not speaking for "we", only for myself: of course.


> 2. Do we collectively agree that the Python ecosystem would benefit
> from an existence checking protocol that permits generalisation of
> algorithms (especially short circuiting ones) across different "data
> missing" indicators, including those defined in the language
> definition, the standard library, and custom user code?

Maybe, but probably not.

Checking for "data missing" or other sentinels is clearly an important 
thing to do, but it remains to be seen whether (1) it should be 
generalised and (2) there is a benefit to making it a protocol.

My sense so far is that generalising beyond None is YAGNI. None of the 
other examples you give strike me as common enough to justify special 
syntax, or even a protocol. I'm not *against* the idea, I just remain 
unconvinced.

But in particular, I *don't* think it is useful to introduce a concept 
similar to "truthiness" for existence. Duck-typing truthiness is useful: 
most of the time, I don't care which truthy value I have, only that it 
is truthy. But I'm having difficulty seeing when I would want to extend 
that to existence checking. The existence singletons are not generally 
interchangeable:

- operator dunder methods don't allow you to pass None instead
  NotImplemented, nor should they;

- (1 + nan) returns a nan, but (1 + Ellipsis) is an error;

- array[...] and array[NotImplemented] probably mean different things;

etc. More on this below.



> 3. Do we collectively agree that it would be easier to use such a
> protocol effectively if existence-checking equivalents to the
> truth-checking "and" and "or" control flow operators were available?

I'm not sure about this one.

[...]
> 4. Do we collectively agree that "?then" and "?else" would be
> reasonable spellings for such operators?

As in...

    spam ?then eggs

meaning (conceptually):

    if (spam is None or spam is NotImplemented 
            or spam is Ellipsis or isnan(spam)):
        return eggs
    else:
        return spam


I don't know... I can't see myself ever not caring which "missing" value 
I have, only that it is "missingly" (by analogy with "truthy").

If I'm writing an operator dunder method, I want to treat NotImplemented 
as "missing", but anything else (None, Ellipsis, NAN) would be a regular 
value. If I'm writing a maths function that supports NANs, I'd probably 
want to treat None, Ellipsis and NotImplemented as errors.

While I agree that "existence checking" is a concept, I don't think 
existence generalises in the same way Truth generalises to truthiness.


> 5a. Do we collectively agree that "access this attribute only if the
> object exists" would be a particularly common use case for such
> operators?

Yes, but only for the "object is not None" case. 

Note that NANs ought to support the same attributes as other 
floats. If they don't, I'd call it an error:

py> nan = float('nan')
py> nan.imag
0.0
py> nan.real
nan

So I shouldn't have to write:

y = x if x.isnan() else x.attr

I should be able to just write:

y = x.attr

and have NANs do the right thing. But if we have a separate, dedicated 
NA/Missing value, like R's NA, things may be different.



> 5b. Do we collectively agree that "access this subscript only if the
> object exists" would be a particularly common use case for such
> operators?

I'd be surprised if it were very common, but it might be "not uncommon".


> 5c. Do we collectively agree that "bind this value to this target only
> if the value currently bound to the target nominally doesn't exist"
> would be a particularly common use case for such operators?

You mean a short-cut for:

    if obj is None:
        obj = spam


Sure, that's very common. But:

    if (obj is None or obj is NotImplemented 
            or obj is Ellipsis or isnan(obj)):
        obj = spam


not so much.


> 6a. Do we collectively agree that 'obj?.attr' would be a reasonable
> spelling for "access this attribute only if the object exists"?

I like that syntax.


> 6b. Do we collectively agree that 'obj?[expr]' would be a reasonable
> spelling for "access this subscript only if the object exists"?
> 6c. Do we collectively agree that 'target ?= expr' would be a
> reasonable spelling for "bind this value to this target only if the
> value currently bound to the target nominally doesn't exist"?

I don't hate either of those.


Thanks for writing the PEP!


-- 
Steve