[Python-Dev] What's the status of PEP 505: None-aware operators?

[Random832]

On Tue, Nov 28, 2017, at 15:31, Raymond Hettinger wrote:
> 
> > I also cc python-dev to see if anybody here is strongly in favor or against this inclusion.
> 
> Put me down for a strong -1.   The proposal would occasionally save a few
> keystokes but comes at the expense of giving Python a more Perlish look
> and a more arcane feel.   
> 
> One of the things I like about Python is that I can walk non-programmers
> through the code and explain what it does.  The examples in PEP 505 look
> like a step in the wrong direction.  They don't "look like Python" and
> make me feel like I have to decrypt the code to figure-out what it does.
> 
>     timeout ?? local_timeout ?? global_timeout
>     'foo' in (None ?? ['foo', 'bar'])
>     requested_quantity ?? default_quantity * price
>     name?.strip()[4:].upper()
>     user?.first_name.upper()

Since we're looking at different syntax for the ?? operator, I have a
suggestion for the ?. operator - and related ?[] and ?() that appeared
in some of the proposals. How about this approach?

Something like (or None: ...) as a syntax block in which any operation
[lexically within the expression, not within e.g. called functions, so
it's different from simply catching AttributeError etc, even if that
could be limited to only catching when the operand is None] on None that
is not valid for None will yield None instead.

This isn't *entirely* equivalent, but offers finer control.

v = name?.strip()[4:].upper() under the old proposal would be more or
less equivalent to:

v = name.strip()[4:].upper() if name is not None else None

Whereas, you could get the same result with:
(or None: name.strip()[4:].upper())

Though that would technically be equivalent to these steps:
v = name.strip if name is not None else None
v = v() if v """""
v = v[4:] """""""
v = v.upper """""""
v = v() """""""

The compiler could optimize this case since it knows none of the
operations are valid on None. This has the advantage of being explicit
about what scope the modified rules apply to, rather than simply
implicitly being "to the end of the chain of dot/bracket/call operators"

It could also be extended to apply, without any additional syntax, to
binary operators (result is None if either operand is None) (or None: a
+ b), for example, could return None if either a or b is none.

[I think I proposed this before with the syntax ?(...), the (or None:
...) is just an idea to make it look more like Python.]