[Python-ideas] except expression
Steven D'Aprano
steve at pearwood.info
Fri Feb 21 01:25:58 CET 2014
On Thu, Feb 20, 2014 at 02:45:56PM +0100, M.-A. Lemburg wrote:
> The colon should stay reserved for starting new blocks of statements.
The colon isn't reserved for starting new blocks of statements, so it
can't "stay" that way.
First we would have to get rid of dict displays, dict comprehensions,
slices and lambda. That will require a PEP, and a period of depreciation
(preferably lasting until Python 5.0, or maybe Python 9.0) before the
existing syntax could be removed.
> The arrow is used for return type annotations, which is a completely
> different concept than returning values.
Well sure, but then + is used for numeric addition and string or list
concatenation, which are similarly different. It isn't a big stretch to
go from "return this value" as code to "return this value" as an
annotation, and an arrow operator -> is an obvious symbol for "map" or
"return". I am surely not the only person who uses notation like:
func -> 42
in sketches to indicate that func returns 42.
> I also find it disturbing that people are actually considering
> to use this expression form as a way to do quick&dirty suppression
> of exceptions.
I'm not surprised in the least. There are bad programmers everywhere,
and I'm sure some of them use Python. But "quick&dirty suppression" is
not the only use-case of this, and some of us are planning to use this
syntax as a way to do appropriately thought-out catching of expressions.
E.g. in the use-case that Raymond originally mentioned, to stop the
proliferation of "default" arguments added to everything and anything
that might raise.
> The intended use case should really be limited to providing default
> values for functions or methods that are expected to return a value.
But not expressions? If you actually mean that, that's a strange
limitation. Why should this be allowed:
one_over(x) except ZeroDivisionError: INF
but not this?
1/x except ZeroDivisionError: INF
> Abusing the fact that procedures in Python return None (simply
> because we don't have procedures and need to use functions instead)
> to make use of except expressions would make code less readable.
That I can agree with!
> Sometimes I wish we had expression objects in Python to wrap
> expressions without evaluating them - sort of like lambdas
> without arguments but with a nicer syntax. These could then
> be used to implement a default() builtin.
Yes to this! But that requires a PEP of its own.
--
Steven
More information about the Python-ideas
mailing list