DoubleVar.set() (I think) goes thru PyObject_Str(),
causing precision loss for doubles:

>>> import Tkinter
>>> import math
>>> x = Tkinter.DoubleVar(Tkinter.Tk())
>>> x.set(math.pi)
>>> x.get()
3.1415926535900001   # not good
>>> math.pi
3.1415926535897931   # original precision
>>> eval(str(math.pi))
3.1415926535900001   # reproduces Tk result
>>>

Reported on c.l.py. Guido says you may know how to
create a "native" Tcl/Tk double in this case instead.

Logged In: YES
user_id=6380

If a proper fix using Tcl float/double objects doesn't work
for some reason, maybe the attached fix (_tkinter.fix) would
work?

Logged In: YES
user_id=21627

I have now fixed this for _tkinter.c 1.154, by passing all
.set arguments with the same object type to Tcl, and
retrieving all Tcl variables with their native type.

This causes slight semantic changes (like the one being
reported as a bug here); most notably:

>>> y=Tkinter.StringVar(Tkinter.Tk())
>>> y.set(3.14)
>>> y.get()
3.1400000000000001

So a StringVar may not return a string anymore if .set did
not enter a string. Does that need to get fixed?

Logged In: YES
user_id=6380

Thanks!

Re StringVar: I think StringVar should coerce the result to
str(), just like IntVar coerces to int(), etc. Maybe
Variable should grow get() method that does no coercion, and
it should no longer be marked as an internal class.

BTW there are a few places in Tkinter docstrings that
promise 0 or 1 where a bool is now returned.

Logged In: YES
user_id=21627

In Tkinter.py 1.172, StringVars now always returns strings
(potentially Unicode); doc strings have been changed to
mention bools.