[Python-ideas] PEP 531: Existence checking operators

[Paul Moore]

On 28 October 2016 at 15:40, Nick Coghlan <ncoghlan at gmail.com> wrote:
> I also don't think the idea is sufficiently general to be worthy of
> dedicated syntax if it's limited specifically to "is not None" checks
> - None's definitely special, but it's not *that* special. Unifying
> None, NaN, NotImplemented and Ellipsis into a meta-category of objects
> that indicate the absence of information rather than a specific value,
> though? And also allowing developers to emulate the protocol for
> testing purposes? That's enough to pique my interest.

I think that's the key for me - new syntax for "is not None" types of
test seems of limited value (sure, other languages have such things,
but that's not compelling - the contexts are different). However, I'm
not convinced by your proposal that we can unify None, NaN,
NotImplemented and Ellipsis in the way you suggest. I wouldn't expect
a[1, None, 2] to mean the same as a[1, ..., 2], so why should an
operator that tested for "Ellipsis or None" be useful? Same for
NotImplemented - we're not proposing to allow rich comparison
operators to return None rather than NotImplemented. The nearest to
plausible is NaN vs None - but even there I don't see the two as the
same.

So, to answer your initial questions, in my opinion:

1. The concept of "checking for existence" is valid.
2. I don't see merging domain-specific values under a common "does not
exist" banner as useful. Specifically, because I wouldn't want the
"does not exist" values to become interchangeable.
3. I don't think there's much value in specific existence-checking
syntax, precisely because I don't view it as a good thing to merge
multiple domain-specific "does not exist", and therefore the benefit
is limited to a shorter way of saying "is not None".

As you noted, given my answers to 1-3, there's not much point in
considering the remaining questions. However, I do think that there's
another concept tied up in the proposals here, that of "short
circuiting attribute access / indexing". The call was for something
that said roughly "a.b if a is not None, otherwise None". But this is
only one form of this pattern - there's a similar pattern, "a.b if a
has an attribute b, otherwise None". And that's been spelled
"getattr(a, 'b', None)" for a long time now. The existence of getattr,
and the fact that no-one is crying out for it to be replaced with
syntax, implies to me that before leaping to a syntax solution we
should be looking at a normal function (possibly a builtin, but maybe
even just a helper). I'd like to see a justification for why "a.b if a
is not None, else None" deserves syntax when "a.b if a has attribute
b, else None" doesn't.

IMO, there's no need for syntax here. There *might* be some benefit in
some helper functions, though. The cynic in me wonders how much of
this debate is rooted in the fact that it's simply more fun to propose
new syntax, than to just write a quick helper and get on with coding
your application...

Paul