Home Original page

Question about Tkinter

Alex Martelli aleaxit at yahoo.com
Fri Aug 10 16:20:08 EDT 2001 
"Grant Edwards" <grante at visi.com> wrote in message
news:slrn9n842d.gjo.grante at grante.comtrol.com...
    ...
> > 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.

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

> Line 15 is where the interesting bit happens.

We do agree on this.  But the lambda is obscuring it a bit:-).

> called.  That function receives one parameter called "event"
> from Tk, and has two default parameters "xx" and "yy" whose
> default values are set when the binding is done.  Since Tk only
> passes the single "event" parameter, "xx" and "yy" will have
> the values specified by "x" and "y" when the lambda operation
> took place.

Same for my favourite solution, except that there is no lambda
form -- the local def takes lambda's place.

> Curry is probably a more readable solution to a non-Schemer.  ;)

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, but
I still dislike _Python's_ lambda, with all of its limits and issues.

A local def appears to me to be a preferable solution in just
about every case.  Giving the callable a somewhat helpful name
is not a big problem, and generally the splitting of a statement
into two that the def forces you to do is no big issue either.

The def lends itself to easier refactoring if you ever need more
than an expression there (again not an earth-shaking issue,
but more important to me than the above ones).


Alex
More information about the Python-list mailing list