tkinter questions: behavior of StringVar, etc
Alan G Isaac
I have a couple questions about tkinter.
1. Where is the list of changes
in Python 3's tkinter?
2. What exactly is the role of the root object,
traditionally created as ``root=tk.Tk()``?
What is an example where one should create this
before creating a Frame instance (which will
otherwise implicitly create one as its master)?
2. Suppose I ``import tkinter as tk`` and
then try ``s1=tk.StringVar()``. This fails
because no "master" is set. Why does a
Variable need a master?
3. Now suppose I set ``root = tk.TK()`` and
then try ``s1=tk.StringVar()``. This
works fine but now seems a bit magical:
how has the value of the "master" been
set?
4. Another bit of magic:
Suppose I ``import tkinter as tk`` and
then try ``f1=tk.Frame()``. This works
fine: apparently calling Frame also
leads to implicit creation of a "master".
Why is what is good for the gander (i.e.,
implicit master creation for a Frame) not
good for the goose (i.e., a Variable)?
(Here I assume that there has been an
answer to 2. above.)
5. Reading around a bit,
it seems common to recommend setting
the values of Variables rather than initializing
them. Why? I cannot see the reason to avoid
``s1=tk.StringVar(value="this works fine")``
and it looks like ``tk.StringVar(()`` is in any
case initialized (to an empty string).
6. Why is str(s1) not its value? More generally,
why does a StringVar not behave more like a string?
Thanks for any insights,
Alan Isaac
Mike Driscoll
Try Google and the Python website. There is tons of info on the Python
wiki:
http://wiki.python.org/moin/TkInter
There are also some books that walk you through Tkinter application
creation, for example,Lutz's "Programming Python".
- Mike
Alan G Isaac
> wrote:
>> I'm a complete newbie to GUI.
>> I have a couple questions about tkinter.
>> 1. Where is the list of changes
>> in Python 3's tkinter?
>> 2. What exactly is the role of the root object,
>> traditionally created as ``root=tk.Tk()``?
>> What is an example where one should create this
>> before creating a Frame instance (which will
>> otherwise implicitly create one as its master)?
>> 2'. Suppose I ``import tkinter as tk`` and
On 3/28/2009 6:19 PM Mike Driscoll apparently wrote:
> Try Google and the Python website. There is tons of info on the Python
> wiki:
> http://wiki.python.org/moin/TkInter
> There are also some books that walk you through Tkinter application
> creation, for example,Lutz's "Programming Python".
Sorry, but I do not see the answers to any of the above
questions, not even the first one. Do you? (One might
believe question 2 is answered, but if you read it, I
think you will see why I do not.)
Cheers,
Alan Isaac
Scott David Daniels
>> On Mar 28, 2:15 pm, Alan G Isaac <alan.is...@gmail.com> wrote:
>>> I'm a complete newbie to GUI. I have a couple questions about tkinter.
>>> 1. Where is the list of changes in Python 3's tkinter?
>>> 2. What exactly is the role of the root object, traditionally
>>> created as ``root=tk.Tk()``?
> On 3/28/2009 6:19 PM Mike Driscoll apparently wrote:
>> Try Google and the Python website. There is tons of info on the Python
>> wiki:
>> http://wiki.python.org/moin/TkInter There are also some books that
>> walk you through Tkinter application creation, for example,Lutz's
>> "Programming Python".
>
> Sorry, but I do not see the answers to any of the above
> questions, not even the first one. Do you? (One might
> believe question 2 is answered, but if you read it, I
> think you will see why I do not.)
OK, that was plain rude. a couple of questions is not six questions.
A reply telling you how to get to some of what you are looking for
is assistance. If you want exact answers to an array of questions,
pay someone to fetch you the answers, or do your own homework.
Clearly I am too grumpy this weekend.
Sorry about that,
--Scott David Daniels
Scott....@Acm.Org
Francesco Bochicchio
I think you need a bit of background (if not, just ignore this post):
1. Tkinter is only a thin wrapper over Tk, a GUI library initially
developed for Tcl language, so many of the answer to the design choices
you question (e.g. what is the master) cannot between answered within
the python documentation but should be searched in the Tcl/Tk
documentation. So google for tcl/tk.
Anyway, all GUI libraries I know of build the GUI as a hierarchical
structure. The master (often called root) ia the root of this
hierarchy, and you have to build it before building the rest.
2. Another good source of information is the source of Tkinter itself,
which is mostly in the Tkinter.py file. This is available in your python
installation, so dig into it: if you for instance look at the __init__
method of the Variable class (which is the basic class of StringVar),
you will easily find the 'magic' to which you refer to.
If you don't like the choices which have been made there (e.g not
automagically creatinga a master for variables but doing it for frames
), you could try and submit a patch :-)
3. Usually the changes between one version of python and the next are
documented (but not in all gory details) in "What is new" documents you
can find in python.org site. I'm not aware of any change for Tkinter,
in Python 3.0 but go read it yourself. If you want more details you
could always fetch the Tkinter.py file (or others) of bot versions and
make a diff.
Ciao
------
FB
Alan G Isaac
> OK, that was plain rude. a couple of questions is not six questions.
> A reply telling you how to get to some of what you are looking for
> is assistance. If you want exact answers to an array of questions,
> pay someone to fetch you the answers, or do your own homework.
>
> Clearly I am too grumpy this weekend.
Yes you are too grumpy. It is *not* rude to point
out that the answers are not where I was pointed.
The available docs are much more focused on "how"
rather than on "why".
Please show me how to use that response to get
even one of the answers. (Please skip #2, since I
fear a repetition of the kind of answer in all the docs,
which is half an answer.) Or, withdraw your claim.
Btw, I cannot find the answers in Grayson's book either.
It's a big book though, and covers much ground, so I
do not deny the answers might well be in there somewhere.
Let's try just these two:
- Why does a Variable need a master?
- If s is a StringVar instance, why is
str(s) its name rather than its value?
Thank you,
Alan Isaac
Alan G Isaac
> 1. Tkinter is only a thin wrapper over Tk, a GUI library initially
> developed for Tcl language, so many of the answer to the design choices
> you question (e.g. what is the master) cannot between answered within
> the python documentation but should be searched in the Tcl/Tk
> documentation. So google for tcl/tk.
> Anyway, all GUI libraries I know of build the GUI as a hierarchical
> structure. The master (often called root) ia the root of this
> hierarchy, and you have to build it before building the rest.
I understand this. But I do not understand what we get
by having each Variable instance register a master.
(In contrast, e.g., to a container widget, such as a Frame,
where I do not have this question.)
> 2. Another good source of information is the source of Tkinter itself,
> which is mostly in the Tkinter.py file.
In Python 3, I'm finding most of the useful stuff to be in
``tkinter/__init__.py``. It is indeed useful, but not
always transparent. At least to a new user.
> if you for instance look at the __init__ method of the
> Variable class (which is the basic class of StringVar),
> you will easily find the 'magic' to which you refer to.
What we find is that Variable is initialized with:
if not master:
master = _default_root
which in turn is initialized to None. I understand this.
Actually, talking this through, I get it now. I was not
properly thinking about the use of module level globals.
Thanks.
> If you don't like the choices which have been made there
> (e.g not automagically creatinga a master for variables
> but doing it for frames ), you could try and submit
> a patch :-)
I am not so presumptuous. I just want to understand why a
Variable needs a master. How is this used?
And, I would like to understand if there is a *reason* that
a StringVar instance, for example, does not behave more like
a string.
> 3. Usually the changes between one version of python and the next are
> documented (but not in all gory details) in "What is new" documents you
> can find in python.org site. I'm not aware of any change
> for Tkinter, in Python 3.0 but go read it yourself.
I did look there, and explicitly got only that the new name
is ``tkinter``. However, there are other changes, e.g. the
names and location of ``colorchooser`` and ``filedialog``.
I realize now that the statement "related modules have been
grouped into packages, and usually the submodule names have
been simplified" is supposed to capture all this, but an
explicit list would have been helpful to me. (And,
I assume, to others.) I also just assumed that some active
user had made a list of changes, which I had overlooked, but
that someone on this list would be aware of.
Thanks,
Alan Isaac
Scott David Daniels
> On 3/29/2009 3:43 AM Scott David Daniels apparently wrote:
>> OK, that was plain rude. a couple of questions is not six questions.
>> A reply telling you how to get to some of what you are looking for
>> is assistance. If you want exact answers to an array of questions,
>> pay someone to fetch you the answers, or do your own homework.
>>
>> Clearly I am too grumpy this weekend.
>
> Yes you are too grumpy. It is *not* rude to point
> out that the answers are not where I was pointed.
> The available docs are much more focused on "how"
> rather than on "why".
>
> I'm a complete newbie to GUI.
> I have a couple questions about tkinter.
>
> 1. Where is the list of changes
> in Python 3's tkinter?
>
> 2. What exactly is the role of the root object,
> traditionally created as ``root=tk.Tk()``?
> before creating a Frame instance (which will
> otherwise implicitly create one as its master)?
The post contains seven numbered questions (two questions are
numbered 2), the first pair of which read like demands. Nowhere
(except the "complete newbie" part) do you say, "I might be
misunderstanding something, but ....", nor do you ask "how can
I find out, ...." You assume there _is_ a "list of changes."
You ask, "What exactly is the role of ...", rather than saying
something like, "I don't understand the role of ...", and continue
to ask why the code is not architected the way you first expected
it to be architected, calling those things you do not understand
"magic" (not "magically" which would at least invoke a sense of
wonder, rather than indignation).
Now I could have rooted around and found the answers to some of your
questions, but I fully expected that your reply would then have been,
"why wasn't that in the documentation," and I was feeling like asking
you to apply for a full refund on your purchase price of your Python.
It looked to me like you had no clue and wanted to learn things your
way. If so, fine, don't ask others for help for free. If not, it
is _your_ responsibility to discover how answers you got were meant
to help you. You really should read:
http://www.catb.org/~esr/faqs/smart-questions.html
> Please show me how to use that response to get
> even one of the answers. (Please skip #2, since I
> fear a repetition of the kind of answer in all the docs,
> which is half an answer.) Or, withdraw your claim.
>
> Btw, I cannot find the answers in Grayson's book either.
> It's a big book though, and covers much ground, so I
> do not deny the answers might well be in there somewhere.
Mike Driscoll said, among other things, "There is tons of info on the
Python wiki: http://wiki.python.org/moin/TkInter" and pointed you
specifically at "Lutz's 'Programming Python'". As far as I can tell,
Grayson is not Lutz's former name :-). People learn in very different
ways. Some people take Grayson's book and are off and running. Lutz
takes a different approach, the Python wiki takes another approach.
Your questions reveal no particular understanding (nor effort), so the
best replies are not to address the individual questions, but to address
how you might get a global understanding. That is how Mike Driscoll's
answer could have helped you.
Remember Python 3.X is a rebuilt Python, so lists of changes would be
useless -- you'd be swamped in detail.
Unfortunately, every GUI system I've seen is swamped in detail, there
are a few core things to understand, but a lot of detail gets addressed
piece by piece. There is no accepted "theory of operation" to learn in
one or two "aha" moments. SO, the people who learn by copy-and-tweak
are much happier working in GUI than the "from first principles" people.
> Let's try just these two:
Actually a couple? Imagine that.
> - Why does a Variable need a master?
> - If s is a StringVar instance, why is
> str(s) its name rather than its value?
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). 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. 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.
So there.
--Scott David Daniels
Scott....@Acm.Org
John Posner
>> You ask, "What exactly is the role of ...", rather than saying
>> something like, "I don't understand the role of ...", and continue
>> to ask why the code is not architected the way you first expected
>> it to be architected, calling those things you do not understand
>> "magic" (not "magically" which would at least invoke a sense of
>> wonder, rather than indignation).
I agree with Scott that Alan could use a little attitude adjustment. OTOH,
the following IDLE transcript does suggest that some "magic" is occurring:
>>> ================================ RESTART
================================
>>> from Tkinter import *
>>> root = Tk()
>>> ss = StringVar()
>>> ================================ RESTART
================================
>>> from Tkinter import *
>>> ss = StringVar()
Traceback (most recent call last):
File "<pyshell#10>", line 1, in <module>
ss = StringVar()
File "C:\Python26\lib\lib-tk\Tkinter.py", line 251, in __init__
Variable.__init__(self, master, value, name)
File "C:\Python26\lib\lib-tk\Tkinter.py", line 182, in __init__
self._tk = master.tk
AttributeError: 'NoneType' object has no attribute 'tk'
Here's the "magic" in this situation, which is not exactly highlighted in
existing Tkinter documentation:
If you do not specify a master object in the StringVar() statement, the
Tk object becomes
the variable's master. If no Tk object exists, an error occurs.
You can create a Tk object explicitly with the Tk() statement. A Tk
object is created
implicitly when you create a widget -- for example, with Frame() or
Entry().
I *did* find this in the "Configuration Interface" section of
Fredrik Lundh's "An Introduction to Tkinter"
(http://www.pythonware.com/media/data/an-introduction-to-tkinter.pdf):
widgetclass(master, option=value, ...) -> widget
Create an instance of this widget class, as a child to the given
master, and using the given options. All options have default
values, so in the simplest case, you only have to specify the
master. You can even leave that out if you really want; Tkinter
then uses the most recently created root window as master.
BTW, the last sentence appears to be false in Python 2.6.1 -- the *first*
root window is used as the master.
E-mail message checked by Spyware Doctor (6.0.0.386)
Database version: 5.12060
http://www.pctools.com/en/spyware-doctor-antivirus/
Alan G Isaac
>> - 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'?
Alan G Isaac
> You ask, "What exactly is the role of ...", rather than
> saying something like, "I don't understand the role of
> ...", and continue to ask why the code is not architected
> the way you first expected it to be architected, calling
> those things you do not understand "magic" (not
> "magically" which would at least invoke a sense of wonder,
> rather than indignation).
Clearly there are some cultural differences here. I am not
a CS type. I would not presume to criticize the
architecture, and in my world, questions are generally
assumed to be what they appear to be: questions.
Additionally, I confess to be completely ignorant of the
nuances you suggest between using the term "magic" and
saying something happened "magically". I meant it only in
the sense that John has since used it: as suggesting
something not obvious (to me) was taking place. I had no
intent to communicate indignation with this term and indeed
am startled that it could be so construed. Is this nuance
really universal on this list?
Cheers,
Alan Isaac
Scott David Daniels
>> 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.
But the answers to your questions lie here. (1) An XxxVar is something
much different than its current contents -- it is an addressable point
in a web of interacting events. The value currently in the XxxVar is
(in many ways) the least interesting thing about it. If you created
the XxxVar before initializing the event system, there would have to be
a funny dance done when that event system got initialized: it would have
to run around and find all of the XxxVars and associate them with the
event system. Also, the XxxVar code would have to know how to behave
when its value is set before the event system is started (as many things
start initialized).
> 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.
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?"
> To elaborate, where could things go wrong if I could
> instantiate a Variable without first instantiating a Tk root
> object? .... [S]uppose 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?
Hmmm -- where cvould things go wrong --- segment fault?
what happens when you call code that hasn't had the setup run?
The initialization of the XxxVar to some fixed value is the first
event generated by that XxxVar. The XxxVar code calls the event
system saying 'blahblah' has been set to 0 or whatever. Once the
event system is running, it can ignore this as nobody (no other
code such as an Entry instance) has expressed an interest. Before
then the data structures may not be in a safe state. What happens
to your TV when you change the channel before turning it on?
> Just to be clear, I am not so presumptuous as to try to
> challenge the design. I am trying to understand it.
But you are trying to understand it by asking why it is
not different from how it currently is. Sometimes the
answer is "because it is the way it is."
> 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'?
I think I answered that above, but here's another try before I'm
done with you: 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. Python has a set of design principles
available through "import this", the second (Explicit is better
than implicit) and twelfth (In the face of ambiguity, refuse the
temptation to guess) apply here. int((1,)) is not 1, it is a failure.
str(("test",)) is "('test',)", not 'test'.
--Scott David Daniels
Scott....@Acm.Org
Rhodri James
wrote:
> On 3/29/2009 2:46 PM Scott David Daniels apparently wrote:
>> You ask, "What exactly is the role of ...", rather than saying
>> something like, "I don't understand the role of ...", and continue to
>> ask why the code is not architected the way you first expected it to be
>> architected, calling those things you do not understand "magic" (not
>> "magically" which would at least invoke a sense of wonder, rather than
>> indignation).
>
>
> Clearly there are some cultural differences here. I am not
> a CS type. I would not presume to criticize the
> architecture, and in my world, questions are generally
> assumed to be what they appear to be: questions.
A question does not stop being a question just because it is
arrogant or respectful, terse or verbose, or whatever else
it manages to communicate. In this case, your choice of wording
(the nearest thing we have in print to "tone of voice") did not
inspire me to go digging around in source that you have just as
easy access to, in order to answer questions that I'm not
particularly interested in.
--
Rhodri James *-* Wildebeeste Herder to the Masses
(Also a bit grumpy this weekend. It must be the weather.)
Alan G Isaac
> In this case, your choice of wording
> (the nearest thing we have in print to "tone of voice") did not
> inspire me to go digging around in source that you have just as
> easy access to, in order to answer questions that I'm not
> particularly interested in.
I certainly was not trying to inspire you to do so.
The question was meant for people who had this
level of understanding already, or who already
knew with some specificity where I might dig.
Since you did not address my question about
the nuance of "magic", I'm inclined to treat
you as a "no" vote.
Thanks,
Alan Isaac
Rhodri James
wrote:
> Since you did not address my question about
> the nuance of "magic", I'm inclined to treat
> you as a "no" vote.
And you'd be wrong.
Alan G Isaac
> 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
Rhodri James
wrote:
> On 3/29/2009 6:49 PM Scott David Daniels apparently wrote:
>> 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.)
s/simplest/safest/. The chances of something going wrong if you
have a staggered setup like that are quite high. The chances of
someone trying to use a ???Var before any of the rest of the
system is set up (and, if they're lucky, seg-faulting) shouldn't
be overlooked either.
Amusingly, I'm just old enough to remember when the answer to
Scott's question was "you probably get static, because the odds
of turning the dial to exactly the right spot are small."
>> 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. ;-)
When you're talking implementation details (which is most of
what we're doing), duck typing does allow you to make mistakes
about what's actually happening. That's the whole point of
it.
Alan G Isaac
> wrote:
>> Since you did not address my question about
>> the nuance of "magic", I'm inclined to treat
>> you as a "no" vote.
On 3/29/2009 7:19 PM Rhodri James apparently wrote:
> And you'd be wrong.
So seriously, you'd read e.g. John's usage
of the term "magic" (in this thread)
to suggest "indignation"?
Curious. But I recognize that cultures differ.
Alan Isaac
Eric Brunel
[snip]
> 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'?
The string representation of Tkinter objects seems to be a design principle in
this module: it'll always evaluate to the representation this object has at
tcl level. Since a XxxVar is represented by an actual variable at tcl level,
its string representation is the name of this variable. I guess it's quite
easier to build the commands that'll be passed to the tcl interpreter this
way: you don't have to check the type of the objects you handle, but pass them
through str and insert the result directly in the command.
HTH
- Eric -
Eric Brunel
> I'm a complete newbie to GUI.
> I have a couple questions about tkinter.
>
> 1. Where is the list of changes
> in Python 3's tkinter?
I'll let someone else answer this as I don't use Python 3 myself. I guess
there are not many.
> 2. What exactly is the role of the root object,
> traditionally created as ``root=tk.Tk()``?
> What is an example where one should create this
> before creating a Frame instance (which will
> otherwise implicitly create one as its master)?
The object traditionally called root is in fact an instance of the tcl
interpreter that will get the commands generated by the Tkinter module. Due to
tk architecture, creating this interpreter will also create a window, which is
inteneded to be your application's main window. This window is called '.' in
tcl/tk. The root object in Tkinter then represents this '.' window. So the
instance of Tk is actually 2 things:
- The interpreter itself;
- The main window for your application.
As for when you should create explicitely an instance of Tk, well, I'd say
always ;-) Creating an instance of Frame without creating a Tk instance first
will actually create one, but you'll have no direct access to it. And you
might want an access to it for quite a number of reasons: hiding it, make it
an icon, add menus to it, and so on... All these operations can be done on
actual windows, not on a Frame which is just a container widget.
> 2. Suppose I ``import tkinter as tk`` and
> then try ``s1=tk.StringVar()``. This fails
> because no "master" is set. Why does a
> Variable need a master?
Because it needs a tcl interpreter to be created. All Tkinter widget actually
reference their interpreter in their tk attribute. The StringVar will probably
just use that.
> 3. Now suppose I set ``root = tk.TK()`` and
> then try ``s1=tk.StringVar()``. This
> works fine but now seems a bit magical:
> how has the value of the "master" been
> set?
The Tk instance is registered in a hidden variable in the Tkinter module. When
you don't specify a master, it'll use the latest created Tk instance one by
default. BTW, the latest should be the only one: it is quite unsafe to create
several Tk instances in the same application.
> 4. Another bit of magic:
> Suppose I ``import tkinter as tk`` and
> then try ``f1=tk.Frame()``. This works
> fine: apparently calling Frame also
> leads to implicit creation of a "master".
> Why is what is good for the gander (i.e.,
> implicit master creation for a Frame) not
> good for the goose (i.e., a Variable)?
> (Here I assume that there has been an
> answer to 2. above.)
Well, I personnally don't see any point on doing any master creation
implicitely, so I never use this master auto-creation for anything. I guess
that having a window automatically created when you just try to instantiate a
variable has been considered weird. But it's just a guess...
> 5. Reading around a bit,
> it seems common to recommend setting
> the values of Variables rather than initializing
> them. Why? I cannot see the reason to avoid
> ``s1=tk.StringVar(value="this works fine")``
> and it looks like ``tk.StringVar(()`` is in any
> case initialized (to an empty string).
I've never seen such a recommendation anywhere. I do tend to rely on the
variable's default values.
> 6. Why is str(s1) not its value? More generally,
> why does a StringVar not behave more like a string?
Well, that's a question for the guys who made the Tkinter module. My guess
would be that StringVar's are supposed to be used only to communicate between
the Python layer and the tcl one. They are not intended to be used as actual
strings in your application. Don't forget anything you do on a StringVar is
actually done by tcl, not Python. So I guess there is also a performance
penalty to use StringVar's instead of Python strings.
> Thanks for any insights,
> Alan Isaac
HTH
- Eric -
Alan G Isaac
> The object traditionally called root is in fact an instance of the tcl
> interpreter that will get the commands generated by the Tkinter module. Due to
> tk architecture, creating this interpreter will also create a window, which is
> inteneded to be your application's main window. This window is called '.' in
> tcl/tk. The root object in Tkinter then represents this '.' window. So the
> instance of Tk is actually 2 things:
> - The interpreter itself;
> - The main window for your application.
OK.
> As for when you should create explicitely an instance of Tk, well, I'd say
> always ;-) Creating an instance of Frame without creating a Tk instance first
> will actually create one, but you'll have no direct access to it.
If I start by creating a frame `f`, then ``f.master`` is the root.
Still, I take your point.
> And you
> might want an access to it for quite a number of reasons: hiding it, make it
> an icon, add menus to it, and so on... All these operations can be done on
> actual windows, not on a Frame which is just a container widget.
Useful. Thanks.
> All Tkinter widget actually
> reference their interpreter in their tk attribute. The StringVar will probably
> just use that.
Yes, I see how this works now.
> The Tk instance is registered in a hidden variable in the Tkinter module. When
> you don't specify a master, it'll use the latest created Tk instance one by
> default. BTW, the latest should be the only one: it is quite unsafe to create
> several Tk instances in the same application.
I have no desire to do this, but might you pin down "unsafe"?
> I guess
> that having a window automatically created when you just try to instantiate a
> variable has been considered weird. But it's just a guess.
Yes, I am making that same guess.
Thanks!
Alan Isaac
Alan G Isaac
> this module: it'll always evaluate to the representation this object has at
> tcl level. Since a XxxVar is represented by an actual variable at tcl level,
> its string representation is the name of this variable. I guess it's quite
> easier to build the commands that'll be passed to the tcl interpreter this
> way: you don't have to check the type of the objects you handle, but pass them
> through str and insert the result directly in the command.
This is a helpful answer: it "feels" right and can be
explored further.
Thanks,
Alan
Eric Brunel
[snip]
>> The Tk instance is registered in a hidden variable in the Tkinter module.
When
>> you don't specify a master, it'll use the latest created Tk instance one by
>> default. BTW, the latest should be the only one: it is quite unsafe to
create
>> several Tk instances in the same application.
>
> I have no desire to do this, but might you pin down "unsafe"?
It is not supposed to be unsafe at tcl level, as it supports several
interpreters side by side in the same application. It is unsafe at user level,
precisely because creating a StringVar might put it in the interpreter you
don't want, leading to weird errors and unexpected results.
So you *can* use several Tk instances in the same application, but then you
really should specify a master for absolutely everything, or you'll get bitten
at some point.
> Thanks!
> Alan Isaac
YW. HTH.
- Eric -
John Posner
>> The Tk instance is registered in a hidden variable in the
>> Tkinter module. When
>> you don't specify a master, it'll use the latest created Tk
>> instance one by
>> default. BTW, the latest should be the only one: it is
>> quite unsafe to create
>> several Tk instances in the same application.
Again, "latest" is incorrect for IDLE 2.6.1:
>>> from Tkinter import *
>>> root1 = Tk()
>>> root2 = Tk()
>>> root3 = Tk()
>>> frm = Frame() # no master specified
>>> frm.master is root3
False
>>> frm.master is root1
True
>> Well, I personnally don't see any point on doing any master creation
>> implicitely, so I never use this master auto-creation for
>> anything.
+1. "Explicit is better than implicit."
-John
E-mail message checked by Spyware Doctor (6.0.0.386)
Database version: 5.12070
http://www.pctools.com/en/spyware-doctor-antivirus/