Tkinter callback arguments
__peter__ at web.de
Wed Nov 4 08:47:45 CET 2009
Alf P. Steinbach wrote:
> * Peter Otten:
>> * Alf P. Steinbach wrote:
>>> * Peter Otten:
>>>> Every time someone has to read the code he will read, hesitate, read
>>>> again, and then hopefully come to the conclusion that the code does
>>>> nothing, consider not using it, or if it is not tied into a larger
>>>> project removing it.
>>> I don't understand what you mean.
>> Writing code is not fire and forget. It has to be debugged, tested,
>> maintained, and will be read quite a few times in the process. Therefore
>> it is important that you make it easy to read and understand.
> No, I meant that I didn't understand why you find it hard to read and
Too many indirections.
>> class IdButton(tkinter.Button):
>> def __init__(self, id, **kw):
>> self.id = id
>> tkinter.Button.__init__(self, **kw)
>> be customised as easily?
> Not unless there's much more that I can learn about tkinter button
> 'command' callbacks. Which is of course possible. :-) Is it possible to
> pick up the relevant object from the handler?
There may be a way using bind(), but the idea was to make simple specialised
subclasses as needed that either invoke a method or take a function that can
be wrapped (something like command = functools.partial(command, self)).
>>>> Example: Why do you introduce button.id_string() instead of
>>> Because the string representation of an id then /can/ be customized
>>> independently of the id. For example, id's might be integers but for
>>> string representation you might want symbolic action names (e.g., you
>>> might have two or more buttons with same title but different actions, so
>>> that title would be ungood to identify button). And for another example,
>>> when debugging or testing you might want the string represention of an
>>> id to provide more information about the button and/or its context, and
>>> then id_string provides a single
>>> central customization point -- provided it's used, of course. <g>
>> And what about the IdEntry class?
> The naming scheme doesn't hold up, but I'm pretty sure that's not what you
I meant that when you need other classes with an .id you will now have to
implement .id_string(), too. A simple approach like
entry = tkinter.Entry(...)
entry.id = 42
won't work anymore.
More information about the Python-list