On Wed, Nov 29, 2017, at 12:40, David Mertz 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 did say, though, that it should only "catch" errors arising from operations that are lexically within the block.
Seeing this, I got an idea in my head of a feature set that (along with expression syntax that has already been suggested), could together fulfill this need and provide more generality.
--- Conditional exception catching ---
"except [ExceptionTypes] [as name] [when condition]" as a syntax to only catch if [condition] is true. the byte code appears to already evaluate an arbitrary condition, it just currently only ever uses it to check types with the special "exception match" compare_op.
We could use "if" as the keyword for conditions instead of "when", but I'm not sure if that creates ambiguity with proposed except-expression syntax when a conditional operator might also be used.
--- Lexical exceptions ---
Have at least some exceptions (say, AttributeError) carry enough information to allow for an exception catching statement to only catch when the exception was caused by the current code, not a function being called. I don't have much idea of how exactly this could work - something to do with the stack trace, maybe? A complicating factor might be that we may want to e.g. catch an AttributeError that comes from a raise statement within a __getattribute__ function, but not from an attribute lookup within such a function.
This could be implemented in a function to be used with the above conditional feature, rather than made another keyword.
--- None-specific exceptions ---
Create a NoneError class to act as a second base class for subclasses of TypeError and AttributeError used when the value causing the error was None. I don't know if the exception catching machinery allows for multiple inheritance, if not, the conditional exception catching feature could be used to use a regular type check instead of the special exception match check [i.e. except as e when isinstance(e, NoneError)]
None might not be special enough to warrant its own syntax, but I think it is special enough for this.