For now Tkinter generates Tk widget names just from Widget instance id.

>>> import tkinter
>>> root = tkinter.Tk()
>>> frame = tkinter.Frame(root)
>>> button = tkinter.Button(frame)
>>> str(button)
'.3070531884.3055478668'

These names are not very readable and distinguishable. I think it would be better to generate names from widget type and short sequential number. For example '.frame#1.button#2' or '.1frame.2button'.

There are some questions:

1. Should numbering be continuous or separate for different types of widgets?

2. Should a number precede or follow a widget type?

3. What separator, prefix or suffix be used? "#" looks too common and can lead to conflicts with user defined names or names generated by Tk or special Tk syntax.

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

> The 'virtue' of the digit strings names is that they match tk behavior (I presume) and are consistently opaque ;-)

No, in Tk you have to give names for all widgets.

frame .main
button .main.ok

This is similar to how classes or functions are declared in Python. The name becomes an attribute of an object and a reference to an object. You shouldn't repeat it twice.

Here is a patch that implements nicer generated widget names.

The problem with ".frame1.button2" or ".frame-1.button-2" is that they look too human readable. If you use explicit names for the part of widgets and allow generating names for other part, there is large chance that generated "button2" or "button-2" will conflict with explicit names. I think we should use something that makes generated names uglier. Maybe prefix them with "_"? "._frame1._button2".

Ah, the patch makes it clear.  Tkinter is already generating a name to submit to tk, and you are proposing to replace using the Python id for that purpose.  +1.

I also notice that duplicate names cause the old tk widget to be destroyed even if the Python instance is not.  Knowing that, I agree with the leading underscore to minimize interference. The consequence of collision and the new default should both be documented somehow.

You can apply show_widget_names.diff to see all widget names. Run IDLE and open the configuration dialog for example.

To make the experiment easy to repeat, say after the patch, I wrote this.  (Perhaps inspired by Ned Batchelder's 'machete debugging' PyCon talk.)

import tkinter as tk
from idlelib.configdialog import ConfigDialog
_realsetup = tk.BaseWidget._setup
def _wrapsetup(self, master, cnf):
    _realsetup(self, master, cnf)
    print(self.widgetName, self._w)
tk.BaseWidget._setup = _wrapsetup
root = tk.Tk()
ConfigDialog(roo)
ttk.BaseWidget._setup = _realsetup

Observations: the longest path rather long: .<num1>.....<num9>.  The root to widget paths collectively represent a tree and, sorted, could be used to populate a tree widget, such as a Treeview.  With the proposed new names, this would give one a useful overview of the total gui, or a part thereof.

If one subclasses a widget, such as class MyFrame(Frame, would the instance .widgetName used in the patch 'Frame' or 'MyFrame'?  The latter would make the treeview really useful, and reward judicious subclassing.

Try this instead.

import tkinter as tk
from idlelib.configdialog import ConfigDialog
from idlelib import macosx

_realsetup = tk.BaseWidget._setup
def _wrapsetup(self, master, cnf):
    _realsetup(self, master, cnf)
    print(self.widgetName, self._w)
tk.BaseWidget._setup = _wrapsetup

root = tk.Tk()
macosx._initializeTkVariantTests(root)
ConfigDialog(root)
tk.BaseWidget._setup = _realsetup

+1 I think would be a nice improvement.

I have experimented with different naming schemes.

Original output with Terry's example (actually names are longer in IDLE, since the configuration dialog is created as a child of other toplevel widget):

label .3070117292.3069168812.3069169068.3069251628.3068822220.3069266540.3068822348.3068839820.3068851532
entry .3070117292.3069168812.3069169068.3069251628.3068822220.3069266540.3068822348.3068839820.3068851628
frame .3070117292.3069168812.3069169068.3069251628.3068822220.3068850604
scrollbar .3070117292.3069168812.3069169068.3069251628.3068822220.3068850604.3068851916
canvas .3070117292.3069168812.3069169068.3069251628.3068822220.3068850604.3068852108
frame .3070117292.3069168812.3069169068.3069251628.3068822220.3068850604.3068852108.3068852428
label .3070117292.3069168812.3069169068.3069251628.3068822220.3068850604.3068852108.3068852428.3068852780
checkbutton .3070117292.3069168812.3069169068.3069251628.3068822220.3068850604.3068852108.3068852428.3068852940

Using Tk command name as a base of a name:

label ._toplevel1._frame1._frame2._frame73._labelframe10._frame127._canvas6._frame128._label28
entry ._toplevel1._frame1._frame2._frame73._labelframe10._frame127._canvas6._frame128._entry9
frame ._toplevel1._frame1._frame2._frame73._labelframe10._frame129
scrollbar ._toplevel1._frame1._frame2._frame73._labelframe10._frame129._scrollbar12
canvas ._toplevel1._frame1._frame2._frame73._labelframe10._frame129._canvas7
frame ._toplevel1._frame1._frame2._frame73._labelframe10._frame129._canvas7._frame130
label ._toplevel1._frame1._frame2._frame73._labelframe10._frame129._canvas7._frame130._label29
checkbutton ._toplevel1._frame1._frame2._frame73._labelframe10._frame129._canvas7._frame130._checkbutton11

Using Python class name:

label ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe6._canvas6._frame105._label28
entry ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe6._canvas6._frame105._entry9
frame ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe7
scrollbar ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe7._scrollbar12
canvas ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe7._canvas7
frame ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe7._canvas7._frame106
label ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe7._canvas7._frame106._label29
checkbutton ._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe7._canvas7._frame106._checkbutton11

It is more informative, but names are usually longer.

Using an abbreviation (upper letters from Python class name in camel style):

label ._cd1._tps1._f1._f61._lf10._vsf6._c14._f105._l32
entry ._cd1._tps1._f1._f61._lf10._vsf6._c14._f105._e9
frame ._cd1._tps1._f1._f61._lf10._vsf7
scrollbar ._cd1._tps1._f1._f61._lf10._vsf7._s13
canvas ._cd1._tps1._f1._f61._lf10._vsf7._c17
frame ._cd1._tps1._f1._f61._lf10._vsf7._c17._f106
label ._cd1._tps1._f1._f61._lf10._vsf7._c17._f106._l33
checkbutton ._cd1._tps1._f1._f61._lf10._vsf7._c17._f106._c18

Names are short, but different classes can have the same abbreviation (e.g. Checkbutton and Canvas). This doesn't cause name clashes, just widget types become non-distinguishable by names.

One problem with these schemes is that they change the rule for avoiding name conflicts. Currently you can just use names that are Python identifier -- they never conflict with generated names. With above schemes you should avoid names starting with an underscore.

Other problem is that they use sequential numbering for every widget type. If you already created 100 frames, the single frame in new window will have name ._frame101. If use separate count for every parent widget, numbers can be smaller (the number is first because it is the serial number of the child in the parent widget):

label .1toplevel.1frame.1frame.5frame.3labelframe.6frame.2canvas.1frame.7label
entry .1toplevel.1frame.1frame.5frame.3labelframe.6frame.2canvas.1frame.8entry
frame .1toplevel.1frame.1frame.5frame.3labelframe.7frame
scrollbar .1toplevel.1frame.1frame.5frame.3labelframe.7frame.1scrollbar
canvas .1toplevel.1frame.1frame.5frame.3labelframe.7frame.2canvas
frame .1toplevel.1frame.1frame.5frame.3labelframe.7frame.2canvas.1frame
label .1toplevel.1frame.1frame.5frame.3labelframe.7frame.2canvas.1frame.1label
checkbutton .1toplevel.1frame.1frame.5frame.3labelframe.7frame.2canvas.1frame.2checkbutton

If use separate numbering for every child type in a parent:

label ._toplevel1._frame1._frame1._frame5._labelframe1._frame6._canvas1._frame1._label4
entry ._toplevel1._frame1._frame1._frame5._labelframe1._frame6._canvas1._frame1._entry2
frame ._toplevel1._frame1._frame1._frame5._labelframe1._frame7
scrollbar ._toplevel1._frame1._frame1._frame5._labelframe1._frame7._scrollbar1
canvas ._toplevel1._frame1._frame1._frame5._labelframe1._frame7._canvas1
frame ._toplevel1._frame1._frame1._frame5._labelframe1._frame7._canvas1._frame1
label ._toplevel1._frame1._frame1._frame5._labelframe1._frame7._canvas1._frame1._label1
checkbutton ._toplevel1._frame1._frame1._frame5._labelframe1._frame7._canvas1._frame1._checkbutton1

While a widget tree could be constructed using tk's introspection functions, I believe there are other good uses for monkey patching.  The attached .py file defines a monkeypatch context manager (does one exist already?).  The file uses the c.m. twice to patch ConfigDialog.CreatePageFontTab so it patches tk for the duration of its call.  The result is 16 rather than 287 lines of output.

>Current (from my program)
>.3070117292.3069168812.3069169068.3069251628.3068822220.3069266540.3068822348.3068839820.3068851532
> Using Tk command name as a base of a name: >._toplevel1._frame1._frame2._frame73._labelframe10._frame127._canvas6._frame128._label28
>Using Python class name:
>._configdialog1._tabbedpageset1._frame1._frame61._labelframe10._verticalscrolledframe6._canvas6._frame105._label28

In the future, the last line might be shortened to
>._config1._notebook1._frame1._frame61._labelframe10._vscrollframe6._canvas6._frame105._label28
which is shorter that the current address-based name. Anyone who cares can either user shorted class names or explicitly gives instances shorter default names.

I don't know what to say about numbering, except that I would prefer any of the options to status quo.

Patch updated.

1. The prefix "0" is used for generated names. This keeps the old rule (generated names start from a digit and are not valid Python identifier) and looks less striking than "_".

2. Lowercased Python class name is used as a base name for generated name.

3. Numbering is separate for every type and every parent widget.

4. Numerical suffix is not used for the first (often the single) child of every type.

I agree with back-compatibility, suppression of '1' suffix, and numbering, which makes suppressed '1' common.

I prefer '1' rather that '0' prefix.  Visually, '1' leaves more space between digit and word.  Semantically, each component represents 1 of something.  0 this, 0 that, 0 etcetera, is a bad semantic clash.

"1" looks too similar to "l".

I based my opinion on trying to actually read and understand the output of tknames.py, with your patch done both ways, in a way that I would do in use.  Since class names always begin with upper case, it did not occur to me to read '1' as anything other than 'one'.  '0' is just as easily confused with 'O'.

In both cases, the resemblance depends on the font.  For the Lucida Console I use for IDLE, there is no internal marker dot or bar and O0 only differ slightly in shape.  In a mixed digits and caps string like '' I might have to type the two to be sure which is which.  On the other hand 1l are much more different, as 1 has a rather long horizontal serif while l has none.  Neither comments are true in the fixed font (Courier?) I see now in Firefox.

The semantic clash problem, which is the bigger problem for me, may be stronger for me as a native speaker.  I read '0Frame' and '1Frame' as 'zero Frame' and 'one Frame', not as arbitrary character sequences.  Being able to switch to semantic reading is the point of this issue.

Generated names are in lower case.

I apologize for my mistake, but it is not of much relevance. My preference is based on my subjective reactions on reading both variations. I used tknames.py, which outputs < 20 names, rather than the code that output > 200 names, because the former seems more realistic and makes it easier to focus on reading one path.

The intellectual justifications and explanations came after and are subsidiary.  If you put yourself in the position of a naive user, do you really prefer reading 'zero toplevel zero frame zero button' or 'one toplevel one frame one button'?  If you prefer the former, then we are simply different and will not agree.

However, I would like to revisit the criteria for a generated name.  Currently, widget names are nearly undocumented, and I don't know of any doc for the 'name=' option.  Our tkinter doc only discusses pathnames in the tcl/tk section, which nearly everyone will skip.  Even there, there is no mention that "button .fred -bg 'red'" translates to "Button(master, name='fred', bg='red')".  The translation obliterates the distinction between 'name' being required and write-once versus 'bg' being optional and rewritable.  In docstrings, 'name' is not listed in Valid resource names, because it is not one.  In help(widget), the pathname only appears in the listing of __str__, nametowidget, and maybe a few other places.

There is no mention of how tkinter generates the required unique name or that it even does so.  The Lundh Tkinterbook makes no mentions of names that I could find.  The Shipman NMU Reference says that name components *are* .n, where n is a stringified int and never mentions, that I could find, the 'name' option to make it otherwise.

The use of 'name=' seems correspondingly rare.  IDLE names 4 Scrollbars (out of about twice as many) 'vbar' or 'hbar'.  It names just a few Menus.  In my reading of stackoverflow tkinter questions, 'name=' is rare there also.  To me, the near absence of name documentation and use gives us latitude in what alternative we pick.

I understand the name clash problem.  For a given master, a person might create a widget with no name and later create a widget of the same class with a name.  The generated name for the first widget, *whatever it is*, might clash with the later name.*  The only way to eliminate all clashes is to check all explicit names.  Join the name to the master name and try to use it in the cheapest way possible, perhaps 'pathname.children'.   If this raises tclerror 'name not recognized'  (or whatever the message is), use the name.  If this succeeds, the name would clash, so raise name clash error.

*The virtue of injecting id(python_widget) after the widget is created is that a user could only calculate the same number before creation with detailed knowledge of id creation.  On CPython, this is tricky, though on other systems, I believe it could just be as simple as id(last widget)+1.

If there is no null value for a default argument, then the most likely explicit argument is a good choice.  For name, that might be the class name or a lower-cased version thereof, possibly suffixed.  The *only* reason to not use that is if clashes with rare but possible future explicit names are deemed too likely.  Ugly, by itself, is bad.  A number prefix is not required.  For other prefixes that would reduce clash possibility, I tried:

>>> for c in "01'|+-*&^%$#@!~` ":
	print(".%stoplevel.%sframe.%sbutton" % (c, c, c))

.0toplevel.0frame.0button
.1toplevel.1frame.1button
.'toplevel.'frame.'button
.|toplevel.|frame.|button
.+toplevel.+frame.+button
.-toplevel.-frame.-button
.*toplevel.*frame.*button
.&toplevel.&frame.&button
.^toplevel.^frame.^button
.%toplevel.%frame.%button
.$toplevel.$frame.$button
.#toplevel.#frame.#button
.@toplevel.@frame.@button
.!toplevel.!frame.!button
.~toplevel.~frame.~button
.`toplevel.`frame.`button
. toplevel. frame. button

I like ` best (unobtrusive and meaningless), ^ second.

` and ^ LGTM. We can change this in any time if it looks bad.

New changeset 304c61263ae6 by Serhiy Storchaka in branch 'default':
Issue #27025: Generated names for Tkinter widgets are now more meanful
https://hg.python.org/cpython/rev/304c61263ae6

The change is a super great idea (see below), but I now think (my suggestion of) '`' is a bad idea because it conflicts with the use of '`' as markup for code and output, as in rst and stackoverflow.

https://stackoverflow.com/questions/37904750/tkinter-tclerror-invalid-command-name-54600176-error-what-is-going-on basically asks

What does '''_tkinter.TclError: invalid command name ".54600176"''' mean?

In my comment to the answer, I noted that 3.6.0a2 now says '''invalid command name ".`label"'''.  I wanted to write `invalid command name ".`label"` to quote it properly, SO style, but this would not work.  So I suggest we invoke your last comment and instead try '^' (or even '~' or '-' if you prefer).

Worse yet, SO replaces a single ` with a space, so that ".`label" is displayed as ". label"

I'm working on a patch that allows to trace all Tcl commands passed from Tkinter, and a number of ".`" in widget names looks not nice.

Now it is clear that '`' is bad prefix.

There are 32 non-alphanumerical non-control ASCII characters: '!', '"', '#', '$', '%', '&', "'", '(', ')', '*', '+', ',', '-', '.', '/', ':', ';', '<', '=', '>', '?', '@', '[', '\\', ']', '^', '_', '`', '{', '|', '}', '~'.

'{', '}', '"', '[', ']', '$', '\\' is basic part of Tcl syntax.
'(' and ')' are used in array indexing.
';' is command delimiter. '#' is a commenting command (and what is more important, it is widely used in generated by Tk widget names).
'.' is component delimiter in widget names.
'-' starts an option.
'%' starts a substitution in callbacks.
'?' and '*' are used in patterns.
"'", ',', and '`' look like grit on my screen.

What is left? '!', '&', '+', '/', ':', '<', '=', '>', '@', '^', '_', '|', '~'.

'@' starts coordinates or image path in some commands.
'~' is expanded to home directory in paths.
'!' is used for comments in X resources.
'|' looks too distant from preceding dot and following name.

Not all of these arguments are absolute stoppers. Personally I like '!', '?' and '@'. Unlikely generated names are saved in X resources or searched by patterns. If you need the widget being named, you just specify a name instead of allowing Tkinter generate arbitrary one.

What are your preferences Terry?

Agreed that ` is not best and should be changed.  An alternative should be in next release.  I looked back at the output in msg268406.

! is similar to | but shorter, and better for that.  It is also, generally, thicker, which is better. With the font used on this page in FireFox, at my usual size setting, |is 1.5 pixels, so it tinged red or green depending on whether the half pixel is to the right or left.  ! is 2 pixels and black, which is better.  Smaller font sizes could reverse the situation, but unlikely for me.

@ is email separator and twitter name prefix.  Firefox recognizes this and colors the first @ and all names blue.  I don't like this.  Not an issue in code editors, etc, but code and especially results, get displayed elsewhere, as here.  Aside from that, it is visually too heavy and I cannot avoid reading @ as 'at'.  Let's skip it.

I still like my previous 2nd choice, ^, but you apparently do not.  I omitted ? before, I think just by oversight.  Let's try both with ! also, isolated from other options.

>>> for c in "^!?":
	print(".%stoplevel.%sframe.%sbutton\n" % (c, c, c))

.^toplevel.^frame.^button

.!toplevel.!frame.!button

.?toplevel.?frame.?button

? strikes me as slightly too heavy, but worse is the semantic meaning of doubt, close to negation.

With the noise of other alternatives removed, and looking again several times, I like ! about as much as ^, both visually and semantically. Perhaps from knowing some Spanish, which uses inverted ! to begin sentences, I read ! as mild affirmation.  I would be equally happy with either.  If you prefer !, go with it.

New changeset 603ac788ed27 by Serhiy Storchaka in branch '3.6':
Issue #27025: Generated names for Tkinter widgets now start by the "!" prefix
https://hg.python.org/cpython/rev/603ac788ed27

New changeset 505949cb2692 by Serhiy Storchaka in branch 'default':
Issue #27025: Generated names for Tkinter widgets now start by the "!" prefix
https://hg.python.org/cpython/rev/505949cb2692

Good point about "@". I missed this.

Thanks Terry. "!" LGTM. Committed to 3.6 too. I consider this as the fix of the bug in 3.6 feature.