Tkinter callback arguments

[Peter Otten]

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

Too many indirections.

> [snip]
>> Couldn't
>> 
>> 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
>>>> str(button.id)?
>>> 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
> mean?

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.

Peter