> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4