Terry J. Reedy added the comment:
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.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue27025>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
