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/)