Tkiniter proposed enhancement; anybody care?
Russell E. Owen
no at spam.invalid
Fri Jun 27 12:42:20 EDT 2003
I posted this to the Python developer's mailing list (via the gmane news
service; my first try so I'm not sure it showed up on the mailing list,
though it showed up fine on gmane) and got no response. So...I'm curious
if anybody saw it, and also if anybody has any reaction.
----------------
I'd like to introduce a small enhancement to Tkinter, but would like
some idea of whether it has a chance of acceptance before proceeding too
far (e.g. before checking in a patch).
The primary change is to add a "name" argument to the Variable.__init__,
bringing it in line with other Tkinter classes. The justification is to
allow users to create new Tkinter variables that point to existing tcl
variables (e.g. somewhat similar to nametowidget). In some cases this
may be more convenient than using setvar and getvar.
Subtlety:
- A new __eq__ method makes two Tkinter variables compare as equal if
they are of the same type and have the same tcl name.
If it is not overreaching, I'd like to introduce a few related changes
at the same time.
1) add a "value" argument to Variable.__init__. This would set the
initial value of the new variable -- a feature I've long wanted.
Subtlety:
- If "name" is specified and the variable already exists, then "value"
is ignored (so the existing value is preserved). One could always ignore
"value" if the variable exists, but I suspect users would prefer to
assume that newly created auto-named variables will be properly
initialized to some default value.
2) add a new function "nametovariable" which returns a Tkinter variable
given the name of a tcl variable.
Subtleties:
- To return a Tkinter variable of the correct class, this requires
changing the auto naming scheme for Tkinter variables. I propose
PY_class_num where class is the appropriate subclass of Variable. This
is the only change that has any danger of affecting existing code.
- If the name does not meet the criteria, a StringVar is returned
- If the tcl variable does not exist, an exception is raised. This is
not necesarry, but prevents accidentaly creating a new variable when one
was trying to point to an existing one.
If this is too much of a change for 2.3b1 but might be considered for
later releases, I'd like some idea if I should submit any of it now or
wait or what.
-- Russell
More information about the Python-list
mailing list