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

Cliff Wells cliff at develix.com
Thu Sep 11 00:13:56 CEST 2008

On Wed, 2008-09-10 at 18:52 -0300, Leonardo Santagada wrote:
> On Sep 10, 2008, at 6:22 PM, Cliff Wells wrote:
> > On Wed, 2008-09-10 at 21:46 +0200, Christian Heimes wrote:
> >> Cliff Wells wrote:
> >>> Any thoughts on this?  I'm sure it's been brought up before, but I
> >>> haven't found any definitive discussions on why this rather  
> >>> arbitrary
> >>> design decision continues to hold in the face of a general migration
> >>> away from imperative languages (especially when it seems it could be
> >>> changed without much backwards-compatibility issues).
> >>
> >> Two thoughts:
> >>
> >> Please elaborate how you like to change the syntax of Python.
> >
> > No changes.  Simply lifting of a particular restriction.
> Two restrictions, both that statements can be used in place of  
> expressions and that statements now return values. But please explain  
> how to do it in a way that is clear. It's a plus if it is backwards  
> compatible :)

Well, one or two, depending on how you word it ;-)  My position is to
simply do away with statements and provide equivalent expressions.

As far as backwards-compatibility, this is legal Python:


It doesn't do anything, but it is valid syntax.  This demonstrates that
expressions can be valid when used independent of a statement,
therefore, the following is also legal (assuming "if" were now
implemented as an expression):

if (a==1):

> >> I like to
> >> see some concrete examples how your syntax would look like. I also  
> >> like
> >> to know how your are planing to implement features like lazy  
> >> evaluation.
> >> The if else ternary operator statement is evaluated lazy. The same
> >> construct as expression wouldn't be lazy any more.
> >
> > Why not?
> >
> > a = (
> >    if a > 1 then:
> >        long_calculation()
> >    else:
> >        other_long_calculation()
> > )
> >
> > Clearly only one of these blocks would be evaluated at runtime.
> And now ifs return a value

Which you are not required to use, just as today:

def foo(x):
    return x**2


> >>
> >> Secondly any syntax change won't happen until we start planing Python
> >> 4000 ;)
> >
> > Yes, that's my expectation, although hopefully PyPy will make some of
> > these things possible to experiment with well before then =)
> You can do that now in PyPy or any other python version... or maybe  
> use Logix to show us a proof of concept version: http://www.livelogix.net/logix/
> Now if I remeber correctly this is already the case of logix, look at:
> http://www.livelogix.net/logix/tutorial/3-Introduction-For-Python-Folks.html#3.1

Yes, Logix is quite interesting.  Unfortunately the author has
discontinued work on it (and was, in fact, unreachable when I last tried
to contact him).   He also mentioned retargeting to another VM (rather
than the Python VM) which made it less appealing to me.

It is interesting that you mention Logix, since it demonstrates that
it's quite possible to be backward-compatible with this particular

> Why would you need lambda then? couldn't you just write x = def (x,y):  
> return x+y ?

Yes, although I suspect that this particular change to "def" would be
more substantial and "lambda" is currently equivalent.   Although this
might satisfy GvR's inclination to dump lambda at some future point ;-)


More information about the Python-ideas mailing list