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

[Eric V. Smith]

> On Nov 29, 2017, at 12:40 PM, David Mertz <mertz at gnosis.cx> wrote:
> 
> 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 being general.
> 
> 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 'Exception'.
> 
> 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.

See the rejected PEP 463 for Exception catching expressions. 

Eric. 

> 
> Yours, David...
> 
> 
>> 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
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
> 
> 
> 
> -- 
> 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.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171129/3a09b3e3/attachment-0001.html>