Tkinter.py, line 1572, 2.3b1 from python.org....

Attempts to compare tcl_version with
_tkinter.TCL_VERSION.  Both have the same value, 8.4,
but...

    tcl_version is a <type 'float'> and
    _tkinter.TCL_VERSION is a <type 'str'>

Temporary kludge: wrap it...    str(tcl_version)

Logged In: YES 
user_id=80475

Eric,  I think this was your change.

Logged In: YES 
user_id=80475

Martin, is this something you can look at in Eric's absence?

Logged In: YES 
user_id=21627

I cannot reproduce this. What operating system is this, what
is the precise Tcl version, and where can I get the source
code of this Tcl version?

Logged In: YES 
user_id=10953

Several of us have encountered this.  Personally, I have seen this with 
Tcl/Tk 8.4.1 under Mac OS X 10.2.4 and MacPython 2.3a2.  ...and with 
Tcl/Tk 8.4.2.  ...and under 10.2.5 and 2.3b1.  I've tried several 
combinations.  

My sources came from ftp://ftp.python.org and http://ftp.cwi.nl/jack/
python/mac/ .  I hope this helps.  

Logged In: YES 
user_id=21627

This seems to happen only in the Mac version of Tcl. I can't
reproduce it on Linux or Windows, and I can't see anything
in the Tcl sources that may causing it.

tcl_version is set in generic/tclBasic.c using Tcl_SetVar,
i.e. as a string. It is never referred-to in the Tcl
sources, except for being returned from 'info tclversion'.
So I can't see why it would ever be changed to a floating
point object.

Perhaps the Mac is not using the original Tcl source code?
Assigning to Jack for further investigation.

Logged In: YES 
user_id=45365

Martin, I'm assigning back to you, because I'm out of my water here. I 
discussed this problem with the MacTcl people, and it seems that what was 
checked in in _tkinter.c for patch 518625 is not correct: if something is 
initialized as a string in Tcl and then some code accesses it as a float the 
internal float representation will be created automatically. In other words:
the FromObj() code attempts to graft Python semantics on Tcl objects, which 
is prone to obscure errors.

Here are some excerpts from relevant mail messages:

-------------

From Jim Ingham:
tcl_version is created as a string variable with the value "8.2".  If somebody 
tried to do some math with it (like evaluate expr $tcl_version <= 8.4 or 
something) then Tcl would set the internal representation to a float.  I don't 
see any place where we are doing that, but maybe your Tkinter code does 
that to check something on Mac OS X?

Anyway that would not be an error on Tcl's part.  If you want tcl_version in 
Python explicitly as a string, you need to make sure the string representation 
exists, and then get the variable as a string.  You can't rely on their being or 
not being any particular internal representation.

------------------

And from Benjamin Riefenstahl:
Well, somebody may already have told you that, but that's not how Tcl
works.  In Tcl *all* values are strings.  You use
Tcl_GetStringFromObj() to get that value.  That's it.  If you want a
floating point, you explicitly *convert* by using
Tcl_GetDoubleFromObj().

Everything you see related to "types" is just internal speed
optimizations to avoid double conversions.  These internal
representations come and go at the whim of the implementation.
Accessing these infos without the official APIs will lead to errors
and inconsistent behaviour, as you have seen.  The details of the
behaviour will also quite likely change from Tcl version to Tcl
version.
---------------

Logged In: YES 
user_id=21627

I disagree that patch #518625 is in error; _tkinter uses
only official Tcl API to access Tcl objects. It is certainly
the case that a computation with tcl_version may cause it to
change its type from string. However, I would still like to
find out where exactly that happens on the Mac, as it
happens nowhere else, and Tkinter most certainly does not
use any Tcl code that may trigger such a change.

Logged In: YES 
user_id=45365

I did some more investigating, and it turns out that Jim and Benjamin's 
analysis of the problem is correct. The distribution that most people install 
for MacOSX is a "batteries included" distribution of Tcl/Tk, which includes 
lots of optional packages that initialize themselves. Some of these 
initializations do a compare of tcl_version to the numeric value 8.3 or so, 
thereby coercing tcl_version to a float. I removed all traces of tcl/tk from my 
machine and installed a minimal tcl/tk and the problem does not occur.

On Linux everyone apparently installs a bare tcl/tk, but once you install 
incrTcl or whatever yourself you will run into the same problem.

As to your (Martin's) statement that _tkinter uses only official Tcl APIs: the 
TCL folks disagree with this. The official way to get a float from a tcl object 
is using Tcl_GetDoubleFromObj(), not looking at the cached internal value. A 
tcl object is a string, and that's all there is. Anything else is optimization.

The question now is really: how important is patch #518625. It apparently 
breaks Tcl object semantics, is the added convenience worth it. If it is then 
we simply add str() calls around the comparison of tcl_version in Tkinter, but 
then we should remember that this same problem will show up in different 
guises later.

Logged In: YES 
user_id=21627

On incrTcl: I still cannot reproduce that. On Linux, incrTcl
is typically installed, but it comes as a Tcl package. So it
won't get loaded until somebody does 'package require Itcl'.
On loading that package, I see no change in type of
tcl_version. Grepping the source of Itcl 3.2.1, I find no
occurrence of tcl_version. What specific file contains what
specific access to tcl_version on your system?

On using internal APIs: I see, using GetDoubleFromObj is
probably better. However, it won't change the behaviour at
all: Python accesses the double representation only if it
already knows the Tcl object is a double. In that case,
Tcl_GetDoubleFromObj does exactly the same thing that
_tkinter already does.

On the importance of #518625: It is important for the
following reasons:
a) it allows to round-trip doubles without loss of precision.
    That fixes #721171.
b) it improves type safety, by returning the proper object
types for widget attributes.
c) it improves efficiency, but not requiring expensive
string-object conversions.
It also provides full backwards compatibility, by allowing
applications to set Tkinter.wantobjects=False.

I'll try to come up with a fix for this bug, although I
would really prefer if I could reproduce it.

Logged In: YES 
user_id=45365

I'm getting fed up with this bug. I uninstalled the Batteries Included 
distribution and installed the minimal TclTkAqua and indeed: everything 
worked as expected. Then I installed BI again, expecting the problem to 
come back, *but it didn't*. Then I asked other people on the PythonMac-SIG 
to do the same: for everyone the problem disappeared with the minimal 
install, for some it came back with the BI install, for some it didn't.

I suggest we add the str() calls around the test of tcl_version and leave it at 
that.

Logged In: YES 
user_id=21627

Fixed as suggested in Tkinter.py 1.175.