[Python-Dev] _tkinter and Tcl/Tk versions

Guido van Rossum guido@python.org
Wed, 05 Apr 2000 10:04:53 -0400


> Guido van Rossum:
> > Modified Files:
> >       FixTk.py 
> > Log Message:
> > Work the Tcl version number in the path we search for.
> [...]
> > ! import sys, os, _tkinter
> > ! ver = str(_tkinter.TCL_VERSION)
> > ! v = os.path.join(sys.prefix, "tcl", "tcl"+ver)
> >   if os.path.exists(os.path.join(v, "init.tcl")):
> >       os.environ["TCL_LIBRARY"] = v
> [...]

Note that this is only used on Windows, where Python is distributed
with a particular version of Tk.  I decided I needed to back down from
8.3 to 8.2 (8.3 sometimes crashes on close) so I decided to make the
FixTk module independent of the version.

> Just a wild idea: 
> 
> Does it make sense to have several incarnations of the shared object file
> _tkinter.so (or _tkinter.pyd on WinXX)?
> 
> Something like _tkint83.so, _tkint82.so and so on, so that
> Tkinter.py can do something like the following to find a
> available Tcl/Tk version:
> 
> for tkversion in range(83,79,-1):
>     try:
>         _tkinter = __import__("_tkint"+str(tkversion))
>         break
>     except ImportError:
>         pass
> else:
>     raise
> 
> Of course this does only make sense on platforms with shared object loading
> and if preparing Python binary distributions without including a 
> particular Tcl/Tk package into the Python package.  This idea might be 
> interesting for Red Hat, SuSE Linux distribution users to allow partial 
> system upgrades with a binary python-1.6.rpm

Can you tell me what problem you are trying to solve here?  It makes
no sense to me, but maybe I'm missing something.  Typically Python is
built to match the Tcl/Tk version you have installed, right?

--Guido van Rossum (home page: http://www.python.org/~guido/)