Re: [Python-ideas] Statements vs Expressions... why?
On Thu, 2008-09-11 at 16:21 -0400, Mike Meyer wrote:
On Thu, 11 Sep 2008 12:45:06 -0700 Cliff Wells
wrote: The thought of running into something like the above in production code is enough to make me bounce pretty much any proposal that would allow it. Compared to that,
a = (18 if x < 23 else 24) + (29 if y < 23 else 81)
a = ( if x < 23: 18 else: 24 ) + ( if y < 23: 29 else: 81 )
And you ignored the constraint that you had to leave the newlines and indentations in the statement.
Sorry, I'm not going to satisfy "now do it with one hand behind your back" sort of challenges. This is the syntax I'm proposing, so why would I provide it any other way?
Also, you've claimed a number of times that you didn't want to change the syntax of python, but this clearly requires a syntax change, as current python syntax doesn't allow multiple colon-separated statements on a line.
No, I stated I didn't want to *add* any additional syntax (i.e. block delimiters, keywords or whatnot), nor do I want to break existing code. I certainly propose changing the grammar (albeit in a demonstrably backwards-compatible way).
Granted, today this is not valid Python, but supporting it doesn't seem to break existing Python code either. This is precisely how Logix does it (from the page I linked you to earlier):
x = if 2+2==4: "I thought so" else: "hmmm..."
In any case, your above code seems intentionally formatted to be unreadable, something that could be achieved under any circumstances. For example, here's your code reformatted in a fashion similar to your first example:
Yup, and if that was what someone was proposing, it'd be a reason to reject it. But nobody is proposing turning expressions into statements, which is what you just did.
No, I turned statements into expressions, which is what I've been proposing since the very first post. I cannot possibly fathom where you came up with the exact opposite. You continue to be stuck in a rut of demanding that something be a statement when this is simply not a requirement. Perfectly legal (although useless) Python: 1 2 3 Note that this does not somehow magically turn numbers into statements. It affirms that expressions can be used as statements (something that is already true in Python). Ask yourself, is a function call a statement or an expression? It's an expression (a function call *always* returns a value), and yet it can be used alone: def foo(x): return x**2 foo(2) # expression used as a statement y = foo(3) # expression used as an expression
What we do gain with the idea I've forwarded is a single, more flexible if-expression in place of an if-statement and an if-operator with inverted syntax.
But that's not what you've been claiming you wanted. You've been claiming you wanted statements to be expressions.
Uh... yeah. Seriously: which part of "this is an example of turning a particular Python statement into an expression" am I not conveying to you?
I claim that doing that makes for ugly code, because statements - with newlines and whitespace as a critical part of the syntax - are ugly to embed in expressions. I've asked for examples and not gotten them. I provide an ugly example of statements embedded in an expressions, and you respond by providing an alternative trinary operator to rewrite it.
I did not. I'm going to let you try to understand that one line of code better after you've realized you wouldn't need an operator if the if-statement were an if-expression.
I still want to see how you propose to embed *statements* into arbitrary expressions, complete with newlines and proper indentation. Say... a = ( if x < 24: go_make_some_side_effects() a_nice_long_function() * another_nice_long_function() else: go_make_different_side_effects() a_twisty_little_function() * a_nice_long_function() ) \ + ( if y < 23: go_make_some_different_side_effects() a_twisty_little_function() * another_nice_long_function() else: go_make_different_side_effects() a_nice_long_function() * a_twisty_little_function() )
This is still simply bletcherous compared to the obvious legal rewrite.
Ignoring your superfluous backslash, the above is a perfectly valid example. Of course, like all contrived examples, it doesn't necessarily convey *why* you'd want to do this, but the syntax is correct. Also, go_make_some_side_effects() is probably ill-advised, and not something usually done in an FP style which you claim to be familiar with. Imperative programming is all about side-effects whereas functional programming is all about avoiding them.
But it's about the cleanest way I've seen to deal with the issue. Using operator.add might be a bit cleaner, but not enough so to justify using operator.add.
And we haven't gotten *really* warped yet, with statements appearing as controlling expressions inside of other statements. While making this "simple" changes allows you to make a few use cases simpler, it also makes some truly ugly things seem reasonable. Frankly, I'd rather let the experts deal with those use cases individually with well-thought out extensions than open this can of worms - unless you can show how to do those kinds of embeddings in ways that *aren't* ugly.
I point you to the entire history of FP programming and we can leave it at that. If you've programmed in Lisp as you claim then I cannot see any reason to rehash what you, by definition, must already know, but keep pretending not to. Unless you're willing to admit you simply don't know FP or that you are being intentionally obtuse for some unfathomable reason, then I'm not interested in pursuing this discussion with you any further. If it's a matter of me not being clear, then I apologize, but frankly I've been as clear as I am able so further discussion would still certainly seem to be fruitless. Regards, Cliff
participants (4)
-
Adam Olsen
-
Bruce Leban
-
Cliff Wells
-
Scott Dial