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.
I don't know if this has been proposed before. C# and VB have it, as do
some C and Javascript implementations. I don't know if it would be
equivalent or subtly different from re-raising if the condition is
false, but even if so it would make it much easier to implement this
sort of logic in an expression.
--- 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.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
