Typcl is an unmaintained extension to use Tcl from Python.
|A Tcl extension to effortlessly to call bidirectionally between Tcl and Python, targeting Tcl >= 8.5 and Python 2.6 - 2.7.
comp.lang.tcl: ANN: libtclpy public release .
Elmer goes the other way. Elmer allows developers to write code in Python and execute it in Tcl. The resulting Tcl interface to the Python code generated by Elmer is transparent to the Tcl user... Python calls appear as Tcl calls ( "foo( 1, "a" )" in Python appears as "foo 1 a" in Tcl, for example) and Python and Tcl data types are automatically mapped (Tcl lists are converted to Python lists, Python dictionaries are returned as Tcl associative arrays, etc.). Elmer also supports Python's "freeze" module, allowing a Python developer to deliver a single library consisting of several Python files "frozen" in to the Tcl application...no need to set PYTHONPATH or have Python source files accompanying the Tcl application.
|Tcl extension which allows you to create python interpreters from within a Tcl application and evaluate python code.
|GNU GPL v3
11Jan05 - Brian Theado - I wonder what it would take to make python into a Tcl loadable dll and have python tkinter be able to access Tcl/Tk functionality that is already running in Tcl? Probably changes to tkinter to allow Tcl functionality to be passed into it after Tcl loaded the python interpreter (as opposed to loading Tcl as a python extension as I suppose it currently does). It would be cool to be able to run tkinter applications bundled as a starkit.
jcw - IOW, starkits and tclkit as "vehicle" for deploying and launching other language systems, even if that other systems happens to be the main language for that particular developer audience. Interesting idea, seems to me it should be doable. Python's import & I/O system are flexible enough to support starkit access and modification. You can create objects which get passed around as files, yet use the starkit VFS. Taking over the Python filesystem calls is another story, so it would not be at the level of transparently mounted VFS access like Tcl 8.4 now has.
To hash it out a bit for Python, I think the following is all it would take:
The result would be transparent access to all Python modules from Python, and a way to create objects which act as files and tie into files stored in the starkit (for "manual" access to any additional files stored in VFS).