Terry J. Reedy added the comment:

First thoughts on the proposal.  I overall like it.  The 'virtue' of the digit 
strings names is that they match tk behavior (I presume) and are consistently 
opaque ;-)  *Someone* will object to change.

Is your proposal to have (_)tkinter add a name= option when not provided by the 
user?  The main problem I see is breaking code that assumes digits if no name= 
options are given.  Is this currently guaranteed?

1. Canvas item ids are, in Python, ints (though I presume int strings in tcl) 
starting with 1.  They number consecutively within canvas, regardless of 
'type'.  I wonder if tk uses them a indexes into an array of items for a 
particular canvas.  I think I prefer sequential within class.

Something else, I believe, generates alphanumeric names similar to what you 
propose.


2. Follow.

3. '#' seems a bit heavy, as it tends to overwhelm '.' as the separator.  I 
think leave it out or use '-'.  ".frame1.button2" or ".frame-1.button-2".  I 
prefer without.  These could be names I would give if I were to add name= 
options all over the place, except that it is too easy to reuse a number.  

Conflicts: tk does not prevent duplicate names by users.
...
>>> entry2
<tkinter.Entry object .e1>
>>> entry
<tkinter.Entry object .e1>
I am not sure of the consequence of this.

The doc could say, "If you want widget names of the form 
<class-name(lowercased)><sequence number> either consistently supply them 
yourself with name= options, or let tkinter supply them for you."

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27025>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to