Tkinter callback arguments

[Alf P. Steinbach]

* Peter Otten:
> Alf P. Steinbach wrote:
> 
>> * Peter Otten:
>>> Alf P. Steinbach wrote:
>>>
>>>>>     for x in range(0,3):
>>>>>         Button(......, command=lambda x=x: function(x))
>>>> An alternative reusable alternative is to create a button-with-id class.
>>>>
>>>> This is my very first Python class so I'm guessing that there are all
>>>> sorts of issues, in particular naming conventions.
>>> Pseudo-private attributes
>> That means there is some way of making attributes private?
> 
> No, there isn't. And the name mangled __attribute is hardly ever needed. Use 
> _attribute to convey the message "If you mess with this attribute you're on 
> your own".

Thanks!


>> Probably that comes across as an inane question but I ask it anyway. I
>> haven't really started to look at Python classes. I'm guessing that by
>> asking here I may learn things that are not obvious from the
>> documentation.
>>
>>
>>> , javaesque getter methods,
>> What do you mean by that?
> 
> In Java you have a private attribute and a public getter method. In Python 
> you can just make the attribute public, i. e.
> 
> # bad
> class A:
>     def __init__(self):
>         self._id = 42
>    def id(self): return self._id
> 
> # good
> class A:
>     def __init__(self):
>         self.id = 42

I think I get the gist that locally saving lines of code, and generally avoiding 
having to write empty argument list parentheses, and thereby also indicating in 
a way that one is accessing a logical data attribute, is considered good in 
Python, which goes to initial development time and the amount of code that one 
must scan to grok it both for definition and usage  --  is that correct?

But the trade-off is inviting modification of a supposedly fixed id, which goes 
to correctness and later fix-it time?


> You can always switch to
> 
> class A: # assuming 3.x
>     @property
>     def id(self):
>         id = arbitrary_code()
>         return id
> 
> later.

Thanks, now I learned about @property... :-)

But when the thing has been used it's much more difficult to restrict the 
functionality (making read-only, breaking code that changes id) than to add 
functionality (making also writeable, breaking none of existing code).

So isn't "later" a bit late to make it read-only, shouldn't that be the initial 
design, and then possibly adding a setter later if id's turn out to not be so 
constant after all?


>> What I associate with Java getter method is mainly the "get" prefix, for
>> Java introspection.
>>
>>
>>> unidiomatic None-checks
>> What's the idiomatic Python way for an optional thing?
> 
> if some_value is None: ...

Thanks!

But why is this preferred?


>> In this case one alternative I see could be to get rid of the
>> __on_tc_command method and more directly tell tkinter.Button to call the
>> relevant function, doing the if-else choice once only in the IdButton
>> constructor.
>>
>> Is that what you mean?
>>
>> I'm thinking more in terms of customization points when I write code.
>>
>> So I tend to avoid hardcoding things internally in methods, instead
>> designing the choices out to where they're accessible to client code.
>>
>>
>>> , broken naming conventions (**args),
>> How to do this argument forwarding in modern style?
> 
> I meant that keyword args are traditionally named kw or kwargs,  the name 
> "args" is normally used for positional arguments:
> 
> def f(*args, **kw):
>     "whatever"

Thanks!

*Note to myself*: check if there are more such conventions.


>> Or is there an alternative to argument forwarding for this example?
>>
>>
>>> spaces in funny places...
>> Bah. ;-)
>>
>>
>>>> And the idea of creating a reusable solution for such a small issue may
>>>> be un-pythonic?
>>> Screw pythonic, the signal/noise ratio is awful in any language.
>>>  
>>>> But just as an example, in Python 3.x,
>>> ...for achieving less in more lines?
>> Now, that's a good Python-independent question! :-)
>>
>> Re your question's the number of lines: /if/ the code is heavily reused
>> then the number of lines doesn't matter since they're only written /once/;
> 
> 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.

Not that it's a shiny example of code that does a lot, but it (1) simplifies and 
shortens creation of buttons with id, and (2) provides a nice start for adding 
other customizations of those buttons, and (3) supports searching for a button 
with given command id, e.g. for purpose of hiding or enable/disable.

If I didn't just want to try out writing a Python class, which I've never done 
before so it appeared interesting, I'd probably just skipped points 2 and 3 and 
written the same functionality as a factory function, like


<code>
import tkinter

def id_button( owner_widget, id, command = None, **kwargs ):
     def tk_command( an_id = id, a_command = command ):
         if a_command is not None: a_command( id )
     return tkinter.Button( owner_widget, kwargs, command = tk_command )

def on_button_click( id ):
     print( "Button " + str( id ) + " clicked!" )

window = tkinter.Tk()

n_buttons = 3
for x in range( 1, n_buttons + 1 ):
     id_button(
         window, id = x, text = "Button " + str( x ), command = on_button_click
         ).pack()

window.mainloop()
</code>


but once you have the class, for whatever reason, it would be silly not to use 
it, especially since it provides points 2 and 3 which the function doesn't.

By the way, I as yet know next to *nothing* about binding of variable references 
within a function such as tk_command above. Probably I've done Unnecessary 
Things(TM) above?


>> the net effect can even be to reduce the total number of lines, or at
>> least the number of apparent function points (or whatever size metric).
>> That's part of what "reusable" means. For example, if the OP used the code
>> then he or she didn't type them lines, but just copy/paste'd them, less
>> work than typing in a lambda definition in every button creation, and more
>> clear code at every creation.
> 
> But most of your code does *nothing*.

See above, points 2 and 3. Most of that class has to do with 2, customization 
ability.


>> Re your question's what (the) reusability achieves.
>>
>> First, when you and others have used such a thing in a number of places
>> then you gain confidence in correctness. For example, you don't wonder
>> whether Python's str type is correct, and when you test your program you
>> don't test the str type implementation. Since it's been used so much you
>> know that it (mainly) is correct, and that any remaining bug in there
>> can't be all that serious, because if it was then it would've surfaced in
>> earlier use of the type.
> 
> The theory may be OK, but in practice it doesn't always work out. 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>


> The 
> programmer will hesitate, wonder whether to use button.id() or 
> button.id_string(), how the two may interconnect... 

Hm, see immediately above.

It's perhaps a different way of thinking?


> It feels more like a hoop to jump through than a helpful service providing 
> tried an tested code.

Yes.

It's the old "every computer science problem can be solved by adding an extra 
layer of indirection".

Sometimes it's nice when you can do that centrally. Retrofitting the indirection 
to existing client code can be hard.


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


>> A centralized, encapsulated piece of code can be tested to death and
>> deemed correct (enough) and frozen, while the application of a code
>> pattern in umpteen places in umpteen programs, generally can't.
> 
> I'd like to see a good test suite for your IdButton class, especially how it 
> copes with the design decision that you can override the on_clicked() stub, 
> or provide a command function, or both.

The design is that for any given IdButton there's a single point of 
responsibility for the click action, namely either a button creation code 
supplies that action, or it relies on the action defined in the class.

I.e. again customization ability, that the button creation code can /override/ 
the class provided action, per button, without getting into general overriding 
of class methods, just by defining a nice little lambda inline in the call.

But as I learn more Python I may perhaps find that overriding class methods can 
also be done that conveniently  --  I don't know, keep in mind I'm a Python 
newbie, and doing Very Much Else than studying Python. :-)


>> Second, when you do find a bug, or need more functionality, or whatever,
>> there's just /one place/ to fix/extend, whatever, instead of updating
>> umpteen places in umpteen programs, and trying to be sure that you've
>> covered all instances and done the right thing every place regardless of
>> local variations (which is pretty hopeless in general, but my experience
>> with that kind of badness has mostly been with C, not Python). More
>> technically, it's reduced redundancy, in this case avoiding redundant
>> application of a code pattern everywhere one needs a button with id (if
>> that happens often). Reduced redundancy = good.
> 
> I agree with that maxim. Incidentally I have just found a nice example of 
> redundancy for you:
> 
>>>>      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?


Cheers, & thanks,

- Alf