> On Nov 29, 2017, at 12:40 PM, David Mertz <me...@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 <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-...@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-...@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
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/