Version 9 of Accessing Tcl and Python from one another

Updated 2014-08-31 06:20:01 by APN

"Typcl [L1 ] ... [i]s an extension to use Tcl from Python."

See also [L2 ]

Also see https://github.com/aidanhs/libtclpy from aidhans for calling Python from Tcl. Announcement at [L3 ]

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.

tcl2py.py !

 What: tclpython
 Where: http://jfontain.free.fr/tclpython.htm
 Description: Tcl extenson which allows you to create python interpreters
        from within a Tcl application and evaluate python code.
        Currently at version 3.1
 Updated: 07/2004
 Contact: mailto:[email protected] (Jean-Luc Fontaine )

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:

  • take the Python dll and all pre-compiled Python library scripts (the "batteries included") and wrap 'em
  • add to that a small Tcl extension which loads and inits the Python DLL, and supports Python callbacks
  • also add a Python module to access starkits (can be done as Tcl file request callbacks)

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

See also Minotaur

Category Language