同时支持 Tcl 和 Python？
我有一个与 Tcl 静态链接的二进制应用程序，前端是 Tcl 解释器。我想为用户提供使用 Python 执行相同命令的功能，作为关键字选项。 Tcl 语法的示例如下：
set_foo -foo 1.0 -bar 3.0 -cat x
所以等效的 Python 可能如下所示：
set_foo(foo=1.0, bar=3.0, cat="x")
构建该程序两次是否更好，一次作为 Tcl 应用程序，一次作为 Python 应用程序？或者只是将所有内容保留为 Tcl，并有一个命令在其解释器中调用 Python 脚本？
这些命令的实现方式使得它们对所使用的脚本语言一无所知。 api 是：
void set_fooCmd(Handler &data);
Handler 是一个 C++ 类，它负责解析选项并将它们提供给命令实现。到目前为止，Handler 是为 Tcl 实现的，但不是为 Python 实现的。
所有直接与 Tcl 交互的代码都位于其自己的目录中，并从程序的其余部分中抽象出调用。
更新： 这不是一个重复的问题： 为科学代码选择前端/解释器
因为他们询问是否从 Tcl 迁移到 Python 还是 Matlab。我已经知道我想同时支持 Tcl 和 Python，并且我非常想知道人们使用了哪些方法。例如：
- 从 Tcl 调用 Python 解释器
- 为 Python 前端和 Tcl 前端编译单独的应用程序。
- 其他一些方法。
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:
- Calling a Python interpreter from Tcl
- Compiling separate applications for a Python front end and a Tcl front end.
- Some other approach.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可能想看看 SWIG 之类的东西，它允许您创建具有简单 C 接口的应用程序（实现您喜欢的任何方式）并将该接口公开给各种其他脚本语言。 SWIG 支持 Tcl 和 Python，以及 Ruby、PHP、Scheme、Perl、以及许多其他语言。
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.
无需开销。
然而，Python 的 tkinter 模块从 Python 调用 Tcl。有先例，但引入太多的接口层似乎很复杂。
这很常见。许多项目都有多种绑定——Python、Tcl、Perl 等。
有一种可能的方法可以稍微简化语言绑定。
修复二进制应用程序以处理简单的文本输入和输出。您将从标准输入读取数据并写入标准输出。
编写收集参数的Python（和Tcl）应用程序，将二进制文件分叉为子进程；并将参数写入二进制文件的 stdid 并从二进制文件的 stdout 读取结果。
Needless overhead.
However, Python's
tkintermodule calls Tcl from Python. There is a precedent, but it seems convoluted to introduce too many interface layers.This is very common. Many projects have multiple bindings -- Python, Tcl, Perl, etc.
There is one possible way to slightly simplify the language binding.
Fix the binary app to work with simple text input and output. You will read from stdin and write to stdout.
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 是完全可嵌入的（只要您记得在
Tcl_CreateInterp之前调用Tcl_FindExecutable），因此您可以这样做，使用少量的 Python 代码来准备 Tcl 脚本，您在同一进程中执行。这将是快速和可靠的（多进程的东西需要上下文切换来进行通信，并且有更多的故障模式），并最大限度地减少所需的额外代码量。来自 Python 的唯一问题是 Tcl 解释器（即 Tcl_CreateInterp 返回的句柄）与当前线程非常强绑定；您无法从其他线程安全地调用它们（因为在实现中使用了大量线程特定的数据，以减少全局锁的数量）。虽然我们可以争论这些差异，但总的来说，这只是一种不同的做事方式；只有当像这样将事物连接在一起时，您才真正需要关心。
如果你的 Python 代码实际上是单线程的，你可以跳过复杂性，直接访问最简单的事情；在某个层面上不安全，但在另一个层面上是安全的。
Tcl's quite thoroughly embeddable (as long as you remember to call
Tcl_FindExecutablebeforeTcl_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.