PEP 312 - Making lambdas implicit worries me, surely it's just the name 'lambda' that is bad...

[Alexander Schmolck]

Dave Brueck <dave at pythonapocrypha.com> writes:

> On Mon, 3 Mar 2003, Alexander Schmolck wrote:
> > Another minor cause of annoyance are things like this:
> >
> >   SOME_GLOBAL_CONST = [(y**2, x**2) for (x,y) in SOME_OTHER_GLOBAL_CONST]
> >   del x, y # I could do without this
> 
> I _do_ do without it, and it doesn't cause any problems.

Yes it does -- maybe not to you but to the people who import your module
(unless you use __all__, or wrap everything like the above in a function
call), because otherwise your module exports rubbish.

And BTW, unless one's lucky, global variables like x, y and i are quite likely
to cause trouble so I see no point in carelessly introducing this pitfall.

I've more than once had situations where a function due to a typo accidently
refered to a global i/x/y (instead of throwing a NameError), mostly because in
interactive sessions one tends to accumulate rubbish like this in global
scope.

> 
> > > - in practice the only time it causes problems is when you're doing
> > > something questionable anyway, like reusing a variable without
> > > initializing it to some known value.
> >
> > Or accidently overwriting a variable (or modulename).
> 
> Perhaps so. I guess I just reacted because I've never seen it happen in
> practice. It seems like it'd be pretty rare in most cases, assuming
> meaningful variable names. It's not too hard to dream up a counterexample,
> but all the counterexamples I dreamt up _seemed_ dreamt up rather than
> real ones. :)

Well, you asked for an example -- I vaguely remember that I did something like
this:

... [time + delta for time in computeTimes()] ...

I then (possibly as an later addition) wanted to use the time module at a
later point in this function (which I had globally imported for other
functions). No big deal.

> 
> > All this might not amount to much, but I do think they violate the spirit of
> > functional programming enough to bias some people who like FP towards map and
> > filter.
> 
> If you say so... do you explicitly delete your for-loop variables too?
> 
> for i in range(5):
>   print i
> del i

In global scope -- yes. Don't you?

> 
> If namespace pollution is a problem for you with listcomps, how are you
> able to avoid it with for-loops? Might not your same problem avoidance
> techniques apply to both?

Ahem, do you still remember how we got here? I claimed that someone with a FP
slant who usually prefers map and filter in python to list comprehesions is
not automatically a Haskell hater.

Do Haskell list comprehensions force you to "use problem avoidance
techniques"? Do map and filter in python force you to "use problem avoidance
techniques"?

alex