[Tkinter-discuss] Strange behavior with python 2.5

Guilherme Polo ggpolo at gmail.com
Sun Nov 16 20:18:54 CET 2008

On Sun, Nov 16, 2008 at 4:59 PM, Vasilis Vlachoudis
<Vasilis.Vlachoudis at cern.ch> wrote:
> Finally I didn't understand, is it a problem of Tkinter or Tk/Tcl?

It is not really a problem. But if you want to blame someone, go for
Python then.

> In
> any case it breaks the behavior of many programs. Moreover returning a
> different object after calling askdirectory it means that there is a
> problem somewhere that changes the default behavior.

The good part is that you know you should expect a string being
returned from askdirectory, so just convert it.

> Apart from type
> casting with str() what is the correct solution?

Note that there is no cast in Python, doing a str(object) where object
is _tkinter.Tcl_Obj gives you a new object.

Now, what kind of correct solution are you after ? Tkinter could do
more conversions in the Tkinter.py wrapper and other files in lib-tk
(or in the tkinter package on py3k), but you would still eventually
get these Tcl_Obj objects in other extensions. Maybe _tkinter.c could
get improved, but it is an open question on how to improve it in this
area, I've done some improvements here by changing the order of
conversion attempts and some other things but didn't advance much on
it. I've also talked with some tcl developers (when I first saw a
Tcl_Obj in Python I found it weird too) about this, looked the perl tk
wrapper (done by hobbs, which undoubtly knows tcl very well) and it
suffers the same kind of problem, and the more acceptable solution was
to leave to the high level wrapper to handle the conversions itself
(so this would end in Tkinter.py and other files in lib-tk). The
problem is that the _tkinter.c is too generic (which is good), so it
never assumes it knows what type of object to expect from tcl, on the
other hand, the module calling _tkinter functions knows what it wants
to receive so this ends up being the most logical place to convert
objects if needed.

On the same line there are other things that could be improved in
_tkinter and Tkinter, so if you have any patches they are all welcome
in bugs.python.org

> Vasilis
> -----Original Message-----
> From: tkinter-discuss-bounces+vasilis.vlachoudis=cern.ch at python.org
> [mailto:tkinter-discuss-bounces+vasilis.vlachoudis=cern.ch at python.org]
> On Behalf Of Guilherme Polo
> Sent: Sunday, 16 November 2008 17:04
> To: Michael Lange; tkinter-discuss at python.org
> Subject: Re: [Tkinter-discuss] Strange behavior with python 2.5
> On Sun, Nov 16, 2008 at 12:43 PM, Michael Lange <klappnase at web.de>
> wrote:
>> On Sat, 15 Nov 2008 19:41:39 -0200
>> "Guilherme Polo" <ggpolo at gmail.com> wrote:
>>> When you get a _tkinter.Tcl_Obj it means _tkinter wasn't able to
>>> detect and convert a received tcl object to a python object. When
> this
>>> happens the best you can do is get the string representation of the
>>> object by doing str(ans2) and then convert the value yourself (if you
>>> want to convert it to something else different than a string).
>>> With Tcl/Tk 8.5 and the current _tkinter you will see this happening
>>> very often, as tcl/tk now shares objects as much as it can. _tkinter
>>> checks for some specific tcl types but since it may receive any kind
>>> of object, like a pixel object, or bytecode object which are part of
>>> tcl (which happens to contain the same representation, that is why
>>> they got shared) it ends up returning this generic Tcl_Obj.
>> I also found this behavior quite often with Tk-8.4 on several linux
> systems,
>> in fact it seemed to me like it is impossible to predict when it will
> occur
>> so unfortunately the only thing which seems to work reliably is
> setting
>> Tkinter.wantobjects to False.
> Setting wantobjects to False is broken in py3k tho.
> It incurs performance penalty too, since you will be working with
> strings only and objects won't be shared. At the same time it saves
> some time in not needing to do any transformations, or any extra
> attempts to transform, since it will always be a string but I don't
> believe this gain shadows the loses.
>> Michael
>> _______________________________________________
>> Tkinter-discuss mailing list
>> Tkinter-discuss at python.org
>> http://mail.python.org/mailman/listinfo/tkinter-discuss
> --
> -- Guilherme H. Polo Goncalves
> _______________________________________________
> Tkinter-discuss mailing list
> Tkinter-discuss at python.org
> http://mail.python.org/mailman/listinfo/tkinter-discuss

-- Guilherme H. Polo Goncalves

More information about the Tkinter-discuss mailing list