Re: [Python-ideas] exception based conditional expression, similar to if-else conditional expression
-1, if this goes through it will be extended to all other compound statements over time and we'll end up with 2 or 3 ways to do every thing.
A much better idea would be to find a way to make all compound statements into expressions, future-proofing the decision and avoiding the redundancy between "compound statement statement" and "compound statement expression".
Python's list of compound statements is pretty thin (just 7), and 4 of these already have expression forms. for ==> list comprehension, iterator expression while ==> list comprehension, iterator if ==> if-else conditional expression def ==> already have lambda expressions try ==> my proposal class ==> Okay, so this one doesn't have a compound statement, but where would you use it? with ==> I haven't had an occasion to use with, so can't think of an example where it could be useful as a compound expression. Seems to me try-except is kind of sticking out here, and I've tried to show what I think are natural and common places where a try-except expression would be appropriate. -- ========================== Jeffrey E. McAninch, PhD Physicist, X-2-IFD Los Alamos National Laboratory Phone: 505-667-0374 Email: mcaninch@lanl.gov ==========================
On Fri, 21 Aug 2009 12:27:26 am Jeff McAninch wrote:
Python's list of compound statements is pretty thin (just 7), and 4 of these already have expression forms.
for ==> list comprehension, iterator expression while ==> list comprehension, iterator if ==> if-else conditional expression
But that one is ugly (that is, I don't think anyone *likes* the syntax, it's just considered the least worst), and some of us consider that its usefulness is dubious, or at least weak. I think the main reason that Python has a ternary if statement is to stop people writing the error-prone: cond and x or y as a short-circuit ternary if.
def ==> already have lambda expressions
try ==> my proposal
class ==> Okay, so this one doesn't have a compound statement, but where would you use it?
But it does have a function:
type("MyClass", (object,), {}) <class '__main__.MyClass'>
Or rather, class is syntactic sugar for the type known as type(), which isn't actually a function, but you call it as if it were one.
with ==> I haven't had an occasion to use with, so can't think of an example where it could be useful as a compound expression.
Seems to me try-except is kind of sticking out here, and I've tried to show what I think are natural and common places where a try-except expression would be appropriate.
At the moment, I would vote: -0 for the general idea -1 if it allows a bare except I could possibly be convinced to change my first vote to +0 if I could see some real examples of code where this would be useful. (However, I don't think there's any power in the universe which could convince me that allowing bare excepts here was a good thing :) Has anyone considered binding to an exception instance? E.g: x = f(x) except (ValueError, TypeError) as e: extract_from(e) -- Steven D'Aprano
Steven D'Aprano wrote:
But that one is ugly (that is, I don't think anyone *likes* the syntax, it's just considered the least worst), and some of us consider that its usefulness is dubious, or at least weak. I think the main reason that Python has a ternary if statement is to stop people writing the error-prone:
cond and x or y
as a short-circuit ternary if.
That's actually a good point - eliminating the persistent use of buggy workarounds was definitely one of the major motivations behind accepting PEP 308. In this case, there *are* no buggy workarounds: if you want to trap exception, you have to use a real statement. Without that additional motivation of bug prevention, I really doubt this proposal is going to go anywhere. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Seems to me try-except is kind of sticking out here, and I've tried to show what I think are natural and common places where a try-except expression would be appropriate. Let me be clear (apparently I wasn't clear enough): I'm not arguing against a try/except expression (or, indeed, any expression). I'm arguing against creating a brand new expression instead of trying to find a way to make the current statements into expressions, which I
On 20 Aug 2009, at 16:27 , Jeff McAninch wrote: think would be both clearer and better for the language as a whole.
Masklinn wrote:
I'm arguing against creating a brand new expression instead of trying to find a way to make the current statements into expressions, which I think would be both clearer and better for the language as a whole.
Many people have tried, and dismally failed to convince Guido that their suggested solution would be of benefit to the language. -- Greg
participants (5)
-
Greg Ewing -
Jeff McAninch -
Masklinn -
Nick Coghlan -
Steven D'Aprano