Supports both Tcl and Python?

Question

I have a binary application statically linked to Tcl, and the front end is a Tcl interpreter. I would like to offer users the ability to use Python to execute the same commands as keyword variations. Sample Tcl syntax:

set_foo -foo 1.0 -bar 3.0 -cat x 

so the python equivalent might look like this:

 set_foo(foo=1.0, bar=3.0, cat="x") 

Is it better to build the program twice, one as a Tcl application, one as a Python application? Or just save everything as Tcl, and you have a command that will call a Python script in its interpreter?

Commands are implemented in such a way that they do not know anything about the scripting language used. Api:

 void set_fooCmd(Handler &data); 

and Handler is a C ++ class that handles parsing parameters and provides them with a command implementation. So far, the Handler is implemented for Tcl, but not Python.

All code directly linked to Tcl is in its own directory and abstracts calls from the rest of the program.

Update: This is not a duplicate question: Choosing an interface / interpreter for scientific code

as they ask whether to move from Tcl to Python or Matlab. I already know that I want to support both Tcl and Python, and I would really like to know what approaches people used. For example:

• Python interpreter call from Tcl
• Compiling standalone applications for the front end of Python and the front end of Tcl.
• Another approach.

Answer 1

Python interpreter call from Tcl

Wrong overhead.

However, the Python tkinter module calls Tcl from Python. There is a precedent, but it seems confusing to introduce too many interface layers.

Compiling standalone applications for the front end of Python and the front end of Tcl.

This is very common. Many projects have several bindings - Python, Tcl, Perl, etc.

There is one possible way to simplify language binding.

• Fix a binary application for working with simple text input and output. You will read from stdin and write to stdout.

• Writing Python (and Tcl) applications that collect parameters expands the binary as a subprocess; and write the parameters to binary stdid and read the results from binary stdout.

Answer 2

You might want to look at something like SWIG , which will allow you to create an application using a simple C interface (any one you like is implemented) and expose this interface to other scripting languages. SWIG supports Tcl and Python, as well as Ruby, PHP, Scheme, Perl, and many others.

Answer 3

Tcl is deeply nested (until you forget to call Tcl_FindExecutable before Tcl_CreateInterp ) so you can do it this way using a small amount of Python code to prepare the Tcl scripts that you execute in the same process. It will be fast and reliable (multiprocessor material requires context switches for communication and has more failure modes) and minimizes the amount of additional code.

The only thing that came from Python is that the Tcl interpreters (i.e., the descriptors returned by Tcl_CreateInterp ) are very strongly tied to the current thread; you cannot safely call them from other threads (due to the amount of use of data depending on the stream in the implementation to reduce the number of global locks). Although we could discuss disagreements, overall this is just another way of doing things; it is only with the interaction of things like this that you really need to take care. If your Python code is actually single-threaded, you can skip the complexity and just go to the simplest thing with direct access; unsafe at one level, but safe at another.