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. Yours, David... On Wed, Nov 29, 2017 at 9:03 AM, Random832 <random...@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@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@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com