[Python-ideas] Statements vs Expressions... why?

Adam Olsen rhamph at gmail.com
Sat Sep 13 21:41:36 CEST 2008

```On Sat, Sep 13, 2008 at 10:02 AM, Cliff Wells <cliff at develix.com> wrote:
> On Fri, 2008-09-12 at 21:56 -0600, Adam Olsen wrote:
>
>> At most, it's a *small* benefit to the language.  It comes a tradeoff,
>> just like a+b rather than add(a, b), or len(x) rather than x.len().
>
> Okay, you kept providing this example and I kept brushing it off because
> I didn't see where you were leading.  Now I do and now I realize that
> I've utterly failed to get the problem across.
>
> Let's use your example from above: a+b vs add(a, b)
>
> a + b is the *exact* semantical equivalent of add(a, b).  They do the
> same thing, they can be used in the same contexts.  The + operator is
> pure semantic sugar (and well-used sugar too).
>
> Now let's imagine things aren't quite so equivalent.  a+b has the same
> result as add(a, b), except you can only use the + operator in one
> particular context: assignment. It cannot be used say, with a comparison
> operator.
>
> So in my imaginary Python, this is legal
>
>  x = 1 + 2
>
> but this is not
>
>  if x < y + 1: pass
>
> and must instead be written
>
>  if x < add(y, 1): pass
>
> Now lets make it even more of an exact comparison.
>
> Let's say the add(x,y) function didn't even exist.  You have to write it
> yourself.  Worse, writing it requires fairly deep knowledge of Python,
> and worse yet, you sometimes must write a different add(x,y) function
> depending on what context you want to use it in.
>
> At this point we've now made your example much closer in spirit to the
> problem I'm attempting to present.

Your explanation would be true, except custom functions can be used as
either statements or expressions!  It is only the existing statements
which are limited to being used as statements, and they're syntactic
sugar.

>> You're claiming we don't have to make that tradeoff.. but you've done
>> *nothing* to substantiate that.  Even logix only adds more complexity,
>> rather than removing and unifying existing syntax.
>
> And you've provided nothing to substantiate this (aside from this
> assertion).
>
> Also, if we combine statements into expressions, how does this not unify
> existing syntax?  Combining two into one is practically the definition
> of "unify".

Merging generator expressions, list comprehensions, and the for-loop
would be unifying.  Making the for-loop also usable as an expression
is generalizing a specific feature.

I've given many examples of why that doesn't work, so I'll assuming
not seeing them was due to the terminology confusion.

--
Adam Olsen, aka Rhamphoryncus

```