Supporting both Tcl and Python?

I have a binary application that is statically linked against Tcl and the front end is the Tcl interpreter. I would like to offer users the capability of using Python to execute the same commands, as keyword options. A sample of the Tcl syntax is:

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 app, one as a Python app? Or just keep everything as Tcl, and have a command that will invoke a Python script in its interpreter?

The commands are implemented in such a way in that they do not know anything about the scripting language used. The api is:

void set_fooCmd(Handler &data);

and the Handler is a C++ class which handles parsing the options and providing them to the command implementation. So far the Handler is implemented for Tcl, but not Python.

All of the code directly interfacing with Tcl is in its own directory, and abstracts away calls from the rest of the program.

Update: This is not a duplicate question to: Picking a front-end/interpreter for a scientific code

as they are asking whether to move from Tcl to Python or Matlab. I already know I want to support both Tcl and Python, and I would very much like to know what approaches people have used. Such as:

1. Calling a Python interpreter from Tc开发者_JAVA技巧l
2. Compiling separate applications for a Python front end and a Tcl front end.
3. Some other approach.

You perhaps want to look at something like SWIG, which will allow you to create an application with a straitforward C interface (implemented any way you like) and expose that interface to a variety of other scripting languages. SWIG supports Tcl and Python, as well as Ruby, PHP, Scheme, Perl, and many others.

Calling a Python interpreter from Tcl

Needless overhead.

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

Compiling separate applications for a Python front end and a Tcl front end.

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

There is one possible way to slightly simplify the language binding.

1. Fix the binary app to work with simple text input and output. You will read from stdin and write to stdout.

2. Write Python (and Tcl) applications that gather the parameters, forks the binary as a subprocess; and write the parameters to the binary's stdid and reads results from the binary's stdout.

Tcl's quite thoroughly embeddable (as long as you remember to call Tcl_FindExecutable before Tcl_CreateInterp) so you could do it that way, using a small amount of Python code to prepare Tcl scripts that you execute in the same process. That'll be fast and reliable (multiprocess stuff requires context switches for communication and has more failure modes) and minimize the amount of extra code required.

The only gotcha coming from Python would be that Tcl interpreters (i.e., the handles returned by Tcl_CreateInterp) are very strongly bound to the current thread; you cannot call them safely from other threads (because of the amount of use of thread-specific data inside the implementation in order to reduce the number of global locks). While we could debate the differences, it's in general just a different way of doing things; it's only when interfacing things together like this that you actually have to care. If your Python code is actually single-threaded anyway, you can skip the complexity and just go straight to the simplest possible thing with direct access; unsafe at one level, but safe at another.