[Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?
mertz at gnosis.cx
Wed Nov 29 12:40:21 EST 2017
I like much of the thinking in Random's approach. But I still think None
isn't quite special enough to warrant it's own syntax.
However, his '(or None: name.strip()[4:].upper())' makes me realize that
what is being asked in all the '?(', '?.', '?[' syntax ideas is a kind of
ternary expression. Except the ternary isn't based on whether a predicate
holds, but rather on whether an exception occurs (AttributeError, KeyError,
TypeError). And the fallback in the ternary is always None rather than
I think we could generalize this to get something both more Pythonic and
more flexible. E.g.:
val = name.strip()[4:].upper() except None
This would just be catching all errors, which is perhaps too broad. But it
*would* allow a fallback other than None:
val = name.strip()[4:].upper() except -1
I think some syntax could be possible to only "catch" some exceptions and
let others propagate. Maybe:
val = name.strip()[4:].upper() except (AttributeError, KeyError): -1
I don't really like throwing a colon in an expression though. Perhaps some
other word or symbol could work instead. How does this read:
val = name.strip()[4:].upper() except -1 in (AttributeError, KeyError)
Where the 'in' clause at the end would be optional, and default to
I'll note that what this idea DOES NOT get us is:
val = timeout ?? local_timeout ?? global_timeout
Those values that are "possibly None" don't raise exceptions, so they
wouldn't apply to this syntax.
On Wed, Nov 29, 2017 at 9:03 AM, Random832 <random832 at fastmail.com> wrote:
> 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.]
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas