tkinter questions: behavior of StringVar, etc

[Alan G Isaac]

On 3/29/2009 6:49 PM Scott David Daniels apparently wrote:
> Right.  Tkinter could have been built to make a root at 
> the first instantiation of a StringVar or IntVar, but it 
> wasn't.  Answering your why is a bit like answering the 
> "Why did Picasso choose primarily blue in his Blue Period, 
> rather than green?"

But this is a fine answer: a choice had to be made, and
nothing much seemed to be at issue, so this was the simpler
(or whatever) choice.  I did not ask for a deeper answer,
but if that is the correct answer, it cannot be expected to
be obvious to those who are new to the code.


> Hmmm -- where cvould things go wrong --- segment fault? 
> what happens when you call code that hasn't had the setup run? 

Again, I do not understand, and I think I explained why.
Of course if the Variable is not registered with Tcl/Tk at
*creation*, it will have to be registered when first
associated with a widget (or in any way with the event
mechanism).  But of course my question was why a Variable
cannot exist independently of the event mechanism.  Since
you did not critique the answer I proposed in my previous
post, I assume you do not have a big problem with it.  If it
is correct, it is the kind of answer I was looking for.


> What happens to your TV when you change the channel before 
> turning it on? 

I think we can agree this is a safe action, but the result
depends  on the kind of TV (and on what "turning it on" means).
So I think your analogy makes my point: allowing
the state of the variable to be registered at use rather than
creation is feasible, although it would perhaps not be best.
(E.g., it would not be simplest.)


> Printing a StrVar is not the same as printing the contents 
> of a StrVar.  Having "magic" conversions happen for you 
> when they can be useful simply allows you to make mistakes 
> about what things are what.

This sounds like an argument against duck typing, and maybe
even an argument for eliminating most of the special method
names, although I'm sure you did not mean it to be this.  ;-)

Thanks for the discussion.  Your willingness to converse
with someone whose initial "tone" irritated you has helped
me to improve my understanding, and hopefully some future
user will find this thread of some use.

Cheers,
Alan Isaac