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

Cliff Wells cliff at develix.com
Fri Sep 12 03:16:41 CEST 2008


On Thu, 2008-09-11 at 15:53 -0600, Adam Olsen wrote:
> On Thu, Sep 11, 2008 at 3:06 PM, Cliff Wells <cliff at develix.com> wrote:
> > 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.
> 
> This isn't true when applied to python.  We're about halfway in
> between, regularly avoiding side effects (immutable int/str, sorted(),
> iteration is generic and only covers reading), while happily doing
> side-effects when appropriate.

Well, I'd argue that *any* statement is causing a side-effect as it
affects the flow of control or values of objects outside its own scope.

Even the following represents one side-effect (defining a class in the
outer scope):

class Foo(object):
    pass

Expressions on the other hand, *evaluate* into the outer scope.  They
must be explicitly assigned to have any long-term effect once they've
completed.

One way to look at it is that statements "push" values into the
enclosing scope whereas expressions "offer" values to it.  I'd call the
"pushing" a side-effect.  Note that I am not claiming side-effects to be
universally bad things (they often are, but they are just as often
unavoidable to do real work, i.e. printing to the terminal).

> Moreover, although iteration is built on mutation (the iterator
> object's state changes as you go through it), good style is to contain
> that in a single function.  The end result is often directly
> translatable into a side-effect-free language, only our version is
> easier to read; all they offer is a guarantee of no side effects.

Not 100% I'm sure I follow this, but I think I might agree ;-)

Cliff




More information about the Python-ideas mailing list