Accessing Tcl and Python from one another

Difference between version 16 and 17 - Previous - Next
** See also **

   * [Minotaur]
   * [http://stackoverflow.com/questions/2519532/example-for-accessing-tcl-functions-from-python]


** Typcl **

http://web.archive.org/web/20160911155836/http://equi4.com/critlib/typcl.README%|%Typcl is an unmaintained extension to use Tcl ''from'' Python.


** libtclpy **

&| What | '''libtclpy''' |&
&| Where | https://github.com/aidanhs/libtclpy |&
&| Description | A Tcl extension to effortlessly to call bidirectionally between Tcl and Python, targeting Tcl >= 8.5 and Python 2.6 - 2.7. |&
&| License | 3-clause BSD |&
&| Updated | 2018-02 |&
&| Contact | [aidanhs] |&

comp.lang.tcl: https://groups.google.com/forum/#!topic/comp.lang.tcl/fWbQWVheQ40%|%ANN: libtclpy public release%|%.
[https://github.com/flightaware/tohil%|%Tohil] is inspired by libtclpy. It is simultaneously a [Python] extension and a Tcl extension that makes it possible to effortlessly call bidirectionally between Tcl and Python

** Elmer **

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


** tclpython **

&| What | '''tclpython''' |&
&| Where | https://github.com/amykyta3/tclpython/ |&
&| Description | [Tcl] extension which allows you to create [python] interpreters from within a Tcl application and evaluate python code. |&
&| License | GNU GPL v3 |&
&| Updated | 2017-09 |&


** Discussion **

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


<<categories>> Foreign Interfaces | Language