tkinter questions: behavior of StringVar, etc

[Alan G Isaac]

> Alan asked:
>> - Why does a Variable need a master? 
>> - If s is a StringVar instance, why is 
>>   str(s) its name rather than its value?

On 3/29/2009 2:46 PM Scott David Daniels apparently wrote:
> The answer to that, grasshopper, lies in the answer to the question, 
> "What are StringVars designed to do?"  StringVars, and IntVars, and ... 
> are elements to receive, hold, and propagate changes to values that 
> will produce effects in the programs behavior or display.  I find 
> IntVars easier to explain, since you get values for numbers lots of 
> ways.  If a slider updates an IntVar, a signal must reach anything 
> "interested" in the value of that IntVar.  For example, you have a 
> rectangle, and a display of its height, width, area, and aspect ratio. 
> If you change the height or the width, the area and aspect ratio need 
> updating (as well as the value in the height or width).

In short, a Variable can have observers.  My question does
not lie here.  At least, you have not persuaded me that it does.


> Rather than building systems where every control maintain 
> lists of what to notify and how to communicate the value, 
> things like IntVars and StringVars work as data store and 
> signal propagation points.  One of the Vars is more Var 
> than value: a place to go to look for the current value, 
> and a place to register for notification when changes 
> happen.  Clearly you cannot signal changes from a variable 
> unless the whole event mechanism is running.


I take this to be the core of your argument: that a Variable
cannot signal to a widget until the event mechanism is up
and running.  But of course if you create e.g. a Frame, the
"root" is automagically created.  So I do not understand
your reasoning.

To elaborate, where could things go wrong if I could
instantiate a Variable without first instantiating a Tk root
object?  You note that the variable would have no work to do
in an event mechanism until that mechanism was created, but
then again, it could not (right?) have an relevant
association under the current architecture until a root was
instantiated.

For example, suppose I want to associate an ``Entry`` with
a ``StringVar``. If I have not already created a root,
I would have to create the ``Entry`` first (which
auotmagically creates the root) and then the ``StringVar``,
but what is the payoff from this restriction?


> A StringVar needs to know where to send signals about its 
> changes.  Thus two different StringVars containing the 
> same text can behave quite differently, as each may be 
> hooked into a different network of event propagation. 

Yes of course.  See above.
Just to be clear, I am not so presumptuous as to try to
challenge the design.  I am trying to understand it.

Here's what I think the answer might be (following a hint
from Francesco).  I think that this restriction serves no
direct function in Python, but is used manage communication
between Python and Tk/Tcl.  That is, the current design
simply ensures that *at creation* a Variable has a corresponding
Tcl variable and is named in a way that matches the order of
creation.  (Roughly.  In addition it looks like multiple Variable
instances can share a name and thus reference a single Tcl
variable.)  While this does not explain why a Variable,
unlike a Widget, will not create a root object on an as
needed basis, it does explain why the root object is
required for Variable creation.

Thanks,
Alan Isaac

PS If you were also offering an answer to the second question,
I missed it altogether, but although it is perhaps slightly
less obvious than with a StringVar, I would ask the same
basic question of an IntVar: why does it not behave more
like an int?  E.g., why is ``int(IntVar(value=5))`` an
error, or at least, why is ``str(IntVar(value=5))`` the name
of the IntVar instead of '5'?