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

Dave Brueck dave at
Tue Mar 4 18:14:32 CET 2003

On Tue, 4 Mar 2003, Alexander Schmolck wrote:

> Dave Brueck <dave at> 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.

No, it is generally a no-no to do "from foo import *" - so much so that it
doesn't even _work_ in some cases (inside a function), so I'm not
especially worried about taking care of people who do it anyway (but if I
did, that's precisely what __all__ is for).

> > 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.

I guess it's a matter of coding style. To me it seems sloppy to be doing a
a whole lot of module-level computation and/or using names of well-known
modules as variables (e.g. using 'os' as a variable name _anywhere_ except
the os module is bound to bite you eventually, regardless of whether or
not listcomps "leak" into your namespace). If you don't have any qualms
about using 'time' as a variable name, surely you've also been bitten by
it when you used it in a for-loop, no?

> > 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?

Nope, never. And it has _never_ caused me problems in practice.

> > 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"?

No and no. And in practice neither do list comps and for-loops.

To-each-his-own-ly y'rs,

More information about the Python-list mailing list