* 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.
[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?
But AFAIK it's not (I got no arguments supplied in the calls when I tested,
although I don't know whether there are any options or whatever to make it
supply an event object argument, say).
And so AFAICS with this code there's no way to get an id in the on-click
(tkinter 'command') handler.
[snip]
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?
To me it would make more sense to
customize the type of the .id value.
That sounds rather complex, like introducing a command pattern or something just
to support some debugging and testing.
[snippety]
This advantage of confidence in correctness can be realized even without
heavy reuse, because the encapsulation that's necessary for reuse, here
having the code in a class, also makes it possible with more centralized
testing.
Was this sentence/paragraph produced by http://pdos.csail.mit.edu/scigen/
?
No. :-) But you're right that testing isn't that much of an issue for
that class. If that's what you meant.
I read it twice but didn't understand it. You probably misplaced a word, but
I can't figure out which one.
In general, if you encapsulate functionality in a class or function definition
or whatever, then you can move that code out to a module (or a package) and you
can then test the module and gain some confidence in its correctness.
In contrast, if you have nearly the same code duplicated in umpteen places,
doing just about the same but with local variations, then testing and especially
fixing it becomes more difficult and time consuming, and doesn't give you added
confidence about any new instances of that code pattern (with own variations).
But in this case the code to be duplicated is so small, just some glue for
calling a handler with an id, that it's difficult to get wrong. Even though
getting that wrong was exactly what this discussion thread started with. And so
the possible savings in the amount of work for testing and fixing is probably
(OK, weasel word) not that much of an issue in this case.
[snippety]
def __on_tk_command( self ):
if self.__specified_command != None:
self.__specified_command( self )
else:
self.on_clicked()
Uh, could you expand on how that's redundant and how to make it less so?
How about
class IdButton(tkinter.Button):
def __init__(self, owner, id, command=None, **kwargs):
tkinter.Button.__init__(
self, owner, kwargs, command=self.on_clicked)
self.id = id
self.specified_command = command
def on_clicked(self):
if self.specified_command is not None:
self.specified_command(self)
The only purpose I can see for on_clicked is that it can be overridden (that was
the purpose in my code too, a central customization point). But if anyone does
that then he or she now has to duplicate the original on_clicked() code, or else
ditch the per button customization via a supplied command handler function. I
feel that forced code duplication, forced redundancy, something you just have to
remember to add in the code, for the only purpose, is ungood.
Cheers,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
