06.08.20 23:32, Chris Angelico пише:
On Fri, Aug 7, 2020 at 6:28 AM
wrote: Have a look at PEP 463, which looks into this in some detail.
I wish this PEP had gained more traction. Sooner or later, everyone wants an expression form of a try/except.
When it comes to expressing "in the event of this exception, I want this default", exception expressions read much more nicely than an equivalent try/except block.
Also, new syntax would keep the rest of the language clean so that don't end up adding dozens of get() methods. Or r having us expand function signatures with default arguments, like min() and max() functions for example.
It would be great if this PEP were to be resurrected.
I'd be happy to work on it again if anyone else has suggestions for better justifications - see the rejection notice at the top of the PEP.
The main problem to me with the exception catching expression is that you need to add the exception name and several keywords, and it makes real-world examples too long, so you will need to split the expression on several lines, and add extra parenthesis. And in this case there is no much difference between expression x = ( <long expression> except LongExceptionName: <other long expression> ) and statement try: x = <long expression> except LongExceptionName: x = <other long expression> (actually the statement may be shorter and better aligned). Other problem specific to the PEP 463 syntax is using colon in expression. Colon is mainly used before indented block in complex statements. It was introduced in this role purely for aesthetic reasons. Using it in other context is very limited (dict display, lambda, annotations, what else?). Even the "if" expression does not use it.