Поддерживает Tcl и Python?

Question

У меня есть двоичное приложение, которое статически связано с 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 ++, который обрабатывает параметры и предоставляет их реализации команды. Пока что обработчик реализован для Tcl, но не для Python.

Весь код, напрямую взаимодействующий с Tcl, находится в своем собственном каталоге и абстрагирует вызовы от остальной части программы.

Обновление: Это не повторяющийся вопрос к: Выбор внешнего интерфейса / интерпретатора для научного кода

поскольку они спрашивают, переходить ли из Tcl в Python или Matlab. Я уже знаю, что хочу поддерживать и Tcl, и Python, и мне очень хотелось бы знать, какие подходы использовали люди. Такие как:

1. Вызов интерпретатора Python из Tcl
2. Компиляция отдельных приложений для внешнего интерфейса Python и внешнего интерфейса Tcl.
3. Какой-то другой подход.

Answer 1

Возможно, вам захочется взглянуть на что-то вроде SWIG , что позволит вам создать приложение с простым интерфейсом C (реализованным так, как вам нравится) и предоставить этот интерфейс множеству других языков сценариев. , SWIG поддерживает Tcl и Python, а также Ruby, PHP, Scheme, Perl, и многие другие.

Answer 2

Tcl достаточно встраиваемо (если вы не забываете вызывать Tcl_FindExecutable до Tcl_CreateInterp), так что вы можете сделать это таким образом, используя небольшой объем кода Python для подготовки сценариев Tcl, которые вы выполняете в том же процессе. Это будет быстро и надежно (многопроцессорность требует переключений контекста для связи и имеет больше режимов отказа) и минимизирует количество дополнительного кода.

Единственное, что придет из Python - это то, что интерпретаторы Tcl (т. Е. Дескрипторы, возвращаемые Tcl_CreateInterp) очень сильно связаны с текущим потоком; Вы не можете безопасно вызывать их из других потоков (из-за объема использования данных, специфичных для потока, внутри реализации для уменьшения количества глобальных блокировок). Хотя мы могли бы обсуждать различия, в целом это просто другой способ действий; только когда вы соединяете такие вещи вместе, вам действительно нужно заботиться. Если ваш код Python на самом деле является однопоточным, вы можете пропустить сложность и просто перейти к самой простой вещи с прямым доступом; небезопасно на одном уровне, но безопасно на другом.

Answer 3

Вызов интерпретатора Python из Tcl

Ненужные накладные расходы.

Однако модуль Python tkinter вызывает Tcl из Python. Прецедент есть, но кажется слишком сложным вводить слишком много интерфейсных слоев.

Компиляция отдельных приложений для внешнего интерфейса Python и внешнего интерфейса Tcl.

Это очень распространено. Многие проекты имеют несколько привязок - Python, Tcl, Perl и т. Д.

Существует один возможный способ немного упростить привязку языка.

1. Исправлено бинарное приложение для работы с простым вводом и выводом текста. Вы будете читать со стандартного ввода и писать в стандартный вывод.

2. Напишите приложения Python (и Tcl), которые собирают параметры, разветвляют двоичный файл как подпроцесс; и записывает параметры в стандартный двоичный файл и считывает результаты из стандартного двоичного файла.