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

Cliff Wells cliff at develix.com
Fri Sep 12 03:01:55 CEST 2008


On Thu, 2008-09-11 at 15:14 -0700, Bruce Leban wrote:
> I agree that making every statement also an expression has merits, as
> does FP. However, you're handwaving about how this fits into python.

Sure.  I intentionally handwave for two reasons:

1) it's a bit of a waste of time to detail something like this when it's
universally rejected
2) I didn't want to bicker over details.  I wanted to forward the
concept.

>  The scope of an if is defined syntactically by indentation. Your
> proposal changes that in some way that I can't quite tell. Is it that
> you can put a single expression between the if and the else? Or
> something else? When would line breaks be optional where they are now
> required?

I'd say anytime it's ambiguous (i.e. much like you would for
parenthesizing any other group of expressions).   

Logix manages some of the ambiguity by defining ';' as an operator that
simply evaluates to the rightmost value.  I think this makes a lot of
sense.

if x: y else: z # seems obvious

if x: y; y+1 else: z; z+1 # evaluates to y+1 or z+1 depending on x

and is equivalent to

if x:
    y
    y+1
else:
    z
    z+1

A the primary question that arises is what to make of assignment.  GvR
is notoriously against allowing constructs such as:

if ( x=1 ): y

and I think his reasoning is sound (this is usually a programming
error).  I tend to think it should allowed (for consistency), but it
could be defined as a syntax error in this context.  At any rate, I'll
resort to the same argument as is used against people who demand static
type declarations: unit testing =).  Frankly, either is acceptable to
me.

One thing that would have to change about assignment is it would
definitely *have* to be an expression (and evaluate to the assigned
value).  Whether it's allowed in any particular context is open.

> Simply saying "make everything an expression" is insufficient. Saying
> "it's just lifting a restriction" is also insufficient. In many
> languages there are restrictions on using the + operators with
> non-numbers. Why can't we just remove that restriction? Well, we have
> to define the precise semantics in order to do that, e.g., what does
> []+{} mean?
> 
> 
> You said that the value of a for loop would have the value [] if it
> didn't include yield, i.e., 
>     for x in y: foo(x)
> 
> evaluates to [] while you said
>     if x: foo(x) else: foo(0)
> evaluates to foo(something). That seems inconsistent. 

> Is that inconsistency a good thing? For that matter, why return a list
> rather than () or an empty generator? [[As an aside: why can't I write
> {foo(x) for x in y} which is the equivalent of doing d[x] = foo(x) for
> all x. I've just written the equivalent loop several times recently.]]

Both evaluate to *something*, just that the non-yielding for-loop
evaluates to an empty list (probably a good indication it's not being
used in an enclosing expression).  It could probably evaluate to None,
if that seemed more reasonable.  I tend to prefer an empty list as it
allows for looping without testing for an iterable.  Incidentally, how
would an empty generator differ from []?  I'll concede it might make
more logical sense, but would it differ in application?

> To answer these questions, the right thing to do is to write a list of
> exactly what new syntax and semantics you are proposing. I'm not
> saying that I (or anyone else) will agree with what you propose but I
> certainly can't agree with the vague proposal you've made so far.

I'd probably defer heavily to an existing implementation that does
exactly what I'm referring to (except I'm not espousing macros or other
metaprogramming facilities Logix provides):

http://www.livelogix.net/logix/index.html

Whether or not this is the ideal situation is arguable, but those
arguments would need to be much further down the road.  Right now
there's not even agreement on whether the overarching concept is even
appropriate for Python.  

Cliff




More information about the Python-ideas mailing list