More human readable generated widget names

[serhiy-storchaka]

BPO	27025
Nosy	@rhettinger, @terryjreedy, @serhiy-storchaka
PRs	[Do Not Merge] Convert Misc/NEWS so that it is managed by towncrier #552
Files	tkinter_names.patch show_widget_names.diff tknames.py tkinter_names2.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/serhiy-storchaka'
closed_at = <Date 2016-10-25.06:57:16.130>
created_at = <Date 2016-05-15.08:04:05.916>
labels = ['3.7', 'type-feature', 'expert-tkinter']
title = 'More human readable generated widget names'
updated_at = <Date 2017-03-31.16:36:31.488>
user = 'https://github.com/serhiy-storchaka'

bugs.python.org fields:

activity = <Date 2017-03-31.16:36:31.488>
actor = 'dstufft'
assignee = 'serhiy.storchaka'
closed = True
closed_date = <Date 2016-10-25.06:57:16.130>
closer = 'serhiy.storchaka'
components = ['Tkinter']
creation = <Date 2016-05-15.08:04:05.916>
creator = 'serhiy.storchaka'
dependencies = []
files = ['42867', '43092', '43118', '43344']
hgrepos = []
issue_num = 27025
keywords = ['patch']
message_count = 25.0
messages = ['265591', '265649', '265652', '265656', '266839', '266851', '266859', '266874', '266878', '266962', '268257', '268289', '268293', '268392', '268395', '268406', '268422', '268423', '268858', '268859', '269422', '279332', '279353', '279360', '279364']
nosy_count = 4.0
nosy_names = ['rhettinger', 'terry.reedy', 'python-dev', 'serhiy.storchaka']
pr_nums = ['552']
priority = 'normal'
resolution = 'fixed'
stage = 'commit review'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue27025'
versions = ['Python 3.6', 'Python 3.7']

[serhiy-storchaka]

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.

[terryjreedy]

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

[serhiy-storchaka]

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

[terryjreedy]

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.

[serhiy-storchaka]

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

[terryjreedy]

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.

[terryjreedy]

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

[rhettinger]

+1 I think would be a nice improvement.

[serhiy-storchaka]

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

[terryjreedy]

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.

[serhiy-storchaka]

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.

[terryjreedy]

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.

[serhiy-storchaka]

"1" looks too similar to "l".