what's wrong with "lambda x : print x/60,x%60"

[Paul Rubin]

Steve Holden <steve at holdenweb.com> writes:
> >   if cond:
> >     my x = 7    # make a new scope for x, goes out of scope at end of if
> >
> If this genuinely troubles you then you can always isolate the scope
> with a function, though of course you also no longer have the code
> inline then.
> >>I don't generally speaking see the point:

The point is something like: it's normal to write
   if cond:
      x = 7
      do_something_with(x)
      # now you don't care about x any more.

Years later, there's some production problem in the middle of the
night and someone has to put in a patch, and they re-use the value in
x for something later in the function, i.e.

     y = x + 3    # since x is still in scope from way up there

and check it in.  Years after THAT, yet another person re-uses the
name x for something, etc.  Yeah, yeah, bad programming practice,
blah, blah, blah, but anyone who's maintained code in the real world
knows this stuff happens all the time.

> Well, as warts go the inability to tightly control the scope of
> variables isn't really that terrible, is it?

I wouldn't say it's as terrible as some things might be, but it
contributes to a sense of sloppiness about Python, that there are
always all these dirty dishes laying around.  Even the encrustation we
call Perl doesn't have this problem; it can not only control scope,
but it has the -T (taint checking) feature that analyzes actual
dataflow from one variable to another and flags you if you do
something dangerous with unchecked user input.  This turns out to be
very useful.  I wish Python had something like it.