On Thu, 2008-09-11 at 15:53 -0600, Adam Olsen wrote:
On Thu, Sep 11, 2008 at 3:06 PM, Cliff Wells <cliff@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