[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