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