[Python-ideas] Statements vs Expressions... why?
cliff at develix.com
Thu Sep 11 23:06:58 CEST 2008
On Thu, 2008-09-11 at 16:21 -0400, Mike Meyer wrote:
> On Thu, 11 Sep 2008 12:45:06 -0700
> Cliff Wells <cliff at develix.com> 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
> > 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:
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:
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
> 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:
> a_nice_long_function() * another_nice_long_function()
> a_twisty_little_function() * a_nice_long_function()
> ) \
> + (
> if y < 23:
> a_twisty_little_function() * another_nice_long_function()
> a_nice_long_function() * a_twisty_little_function()
> This is still simply bletcherous compared to the obvious legal
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*
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
More information about the Python-ideas