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 -- http://mail.python.org/mailman/listinfo/python-list
