Question about Tkinter

[Alex Martelli]

"Grant Edwards" <grante at visi.com> wrote in message
news:slrn9n9auf.114.grante at tuxtop.visi.com...
> On Fri, 10 Aug 2001 22:20:08 +0200, Alex Martelli <aleaxit at yahoo.com>
wrote:
> >    ...
> >> > Use different callables for the callbacks -- if it must be
> >    ...
> >> A slightly different way is to use lamgda.  It's best for
> >> simple cases where you just want to pass a few arguments that
> >
> >I disagree with your claim that it's best.
>
> My phrasing was bad.  What I meant was that of the various
> situations where one might use lambda the simplest cases are
> the best candidates for lambda usage.  I wasn't claiming that
> lambda is the best option compared to curry or local defs.

Then I completely agree with you!  Yes, if you do want to use
lambda, using it in simple cases is much better than using it
in complicated cases.


> >>  15    b.bind("<Button-1>",lambda event,xx=x,yy=y:
board.toggleSpace(xx,yy))
> >
> >I'd code this (assuming no nested scope, just as you're
> >assuming):
> >
> >         def togglethis(event, xx=x,yy=y):
> >             board.toggleSpace(xx,yy)
> >         b.bind("<Button-1>", togglethis)
>
> That's definitely better.  For some reason (undoubtedly due to
> restrictions in other languages) I often forget that I can use
> a "def" inside the body of a function.

It's easy to forget it, which is why I keep posting subtle
reminders thereof:-).  C and C++ don't let one nest functions,
and while that does simplify the language, sometimes it's
slightly constraining.  (Scheme, OTOH, is quite happy with
nested functions -- be they named or unnamed -- indeed,
the named form is defined in term of the unnamed lambda
form, which seems quite a bit better than giving named and
unnamed forms of nested functions different abilities, as
Python does:-).

> In this case, it's probably a lambda because this program was
> translated from Scheme, and it was already a lambda. :)

Ability to transliterate from other languages to Python is
indeed often useful (e.g. for didactical purposes) so it's
good to keep in mind possible structural parallels.  Alas,
Python's lambda is so constrained that it's rare one can
use it for transliteration (although when the body is just
an expression, it's indeed possible).


> >I am or used to be enough of a schemer that our common-lisp
> >friend recently caught me out as an adorer of tail recursion,
>
> Yup, I was recentlry caught with my Scheme history showing when I
> assumed that recursion was a preferred flow-control mechanism
> in CL.

So we're in the same boat:-).


> >but I still dislike _Python's_ lambda, with all of its limits
> >and issues.
>
> It's obscure _and_ crippled.  One or the other could be
> tolerated.  I've been tripped up by lambda's scoping issues
> more than once (but local def's have the same problem -- at
> least for now).

"from __future__ import" is your friend (for either lambda
or local def).  But the 'crippled' part doesn't go away (with
lambda -- no such issues with local def).


> >A local def appears to me to be a preferable solution in just
> >about every case.
>
> I can't really come up with an example where a lamba is
> superior to a local def for anything that's not completely
> trivial.  The only place a lamba seems like a good option is
> applying a trivial function using map() or filter(). But, that
> usage has been made largely redundant with list comprehensions.

Good point.  Yes, that was one important effect of list
comprehensions.


> But -- since there's no such thing as tuple-comprehensions,
> you still need filter() if you're working with tuples, so maybe
> lambda still has some utility is situations like:
>
>  t2 = filter(lambda x: x>0, t1)

Yes, looks better than t2 = tuple([x for x in t1 if x>0]), although
the latter may be more readable (not everybody knows that
filter, while returning a list for most kinds of input sequences,
returns a tuple when the argument is a tuple and a string
when the argument is a string).

> On a completely different topic, I don't quite understand why,
> when passed a tuple, map() returns a list and filter() returns
> a tuple.  I was quite surprised that they do different things.

It may violate the principle of least astonishment, particularly
since it doesn't generalize to ALL kinds of sequences, just
tuples and strings (for anything else, filter returns a list).


Alex