Рекомендации по взаимодействию perl-to-python?

Question

У нас есть значительная база кода на Perl. В обозримом будущем наша кодовая база останется в Perl. Тем не менее, мы собираемся добавить утилиту на основе графического интерфейса. Мы рассматриваем написание инструментальной панели на Python (используя tkinter или wx). Проблема, однако, заключается в том, что мы хотели бы использовать нашу существующую кодовую базу Perl в графическом интерфейсе Python.

Итак ... какие-либо предложения о том, как этого добиться? Мы рассматриваем несколько вариантов:

1. Запись исполняемых файлов (на Perl), которые имитируют вызовы функций; вызывайте эти исполняемые файлы Perl в python как системные вызовы.
2. Напишите исполняемые файлы Perl на лету внутри панели инструментов Python и вызовите (временный) исполняемый файл Perl.
3. Найдите какой-нибудь конвертер Perl-to-Python или привязку.

Есть еще идеи? Я хотел бы услышать, сталкивались ли другие люди с этой проблемой. К сожалению, сейчас нет возможности конвертировать саму кодовую базу в Python.

Answer 1

Я ненавижу быть другим в хоре, но ...

1. Избегайте использования альтернативного языка
2. Используйте Wx, чтобы его естественный внешний вид делал приложение "реальным" для нетехнической аудитории.
3. Загрузите исходный код Padre и посмотрите, как он работает с кодом Wx Perl, а затем без промедления украдите его лучшие трюки или, может быть, просто проглотите его и используйте скелет приложения (используя художественную половину двойной лицензии Perl, чтобы сделать ее легальной).
4. Создайте свой собственный подкласс Strawberry Perl, чтобы упаковать приложение в качестве установщика MSI и распространить его через корпоративный домен Active Directory.

Конечно, я говорю все это только потому, что вы сказали «Панель инструментов», которую я прочитал как «Корпоративный», что затем заставляет меня принять сеть Microsoft AD ...

Answer 2

Вы можете порождать дочерний процесс и использовать механизм IPC, такой как сокеты или STDIO, или даже вставлять один интерпретатор в другой .

Но зачем переключать языки, когда Perl предлагает несколько привязок Tk ( Tk , Tkx и Tcl :: Tk ) и очень способную Wx связывание

Я написал и распространил проекты GUI с библиотеками Perl Tk и Wx.

Если вам нужна возможность создавать автономные исполняемые файлы, посмотрите PAR :: Packer , PerlApp ActiveState и Cava Pacakger .

Answer 3

Попробуйте дистрибутив CPAN Python (pyperl) для взаимодействия с кодом Python.

Answer 4

Что ж, если вы действительно хотите написать графический интерфейс на другом языке (что, на самом деле, просто плохая идея, так как это будет стоить вам больше, чем могло бы принести вам пользу), вам нужно сделать следующее:

1. Документируйте свое Perl-приложение с точки зрения предоставляемых услуг. Это следует сделать с помощью определения схемы XML - XSD - для типов данных и языка описания веб-служб - WSDL - для реальной службы.
2. Реализуйте сервисы в Perl, возможно используя Catalyst :: Controller :: SOAP или просто XML :: Compile :: SOAP.
3. Использование сервисов из вашего интерфейса на любом языке.
4. Profit.

Но, честно говоря, я действительно предлагаю вам взглянуть на привязку Perl GTK2, это удивительно, включая такие функции, как полная реализация класса Gtk в Perl и использование его в качестве аргумента функции, написанной на C - например, может написать класс модели для дерева gtk полностью на Perl.

Answer 5

Интересный проект: я бы выбрал слабую связь и рассмотрел подход на основе XML-RPC или JSON.

Answer 6

Я думаю, что основным критерием для любого квалифицированного ответа будут детали существующей кодовой базы. Как называется этот Perl-код и как он возвращает результаты?

Набор утилит командной строки, возвращающих результаты через достаточно хороший текстовый вывод («хорошо», как «поддается дальнейшему машинному разбору» или «дружественный конвейеру») ... должен быть достаточно простым для вызова из любого языка программирования (и Отличные модули Python subprocess и multiprocessing в частности). К коллекции веб-CGI или других модулей, расположенных между Apache и некоторой системой СУБД, все равно можно получить доступ с помощью таких вещей, как urlopen2 или mechanize, но может быть лучше обойти код Perl и написать Python запросить базовую (предположительно каноническую) модель (хранилище данных).

Если большая часть кодовой базы представляет собой набор библиотек или модулей ... и функциональность, которая требуется для предлагаемой панели мониторинга, еще не раскрыта через какой-либо механизм более высокого уровня (некоторый интерфейс командной строки, сетевой протокол и т. Д.) .. тогда, в принципе, безумно думать о взаимодействии с ним через любой язык, кроме Perl. (Если, по какому-то странному и крайне маловероятному повороту судьбы, ваша существующая кодовая база и предполагаемая цель реализации уже стабильны в Parrot ).

Давайте зададим другой, более широкий вопрос: Какой интерфейс вы намереваетесь использовать между вашей приборной панелью и существующей кодовой базой?

Этот вопрос имеет первостепенное значение независимо от вашего выбора языка реализации. Если вы пишете панель инструментов на Perl, ей все равно нужно каким-то образом вызывать существующую кодовую базу. Вам, вероятно, нужно исправить свою кодовую базу, чтобы реализовать поддержку всего, что вы собираетесь использовать для своей инструментальной панели. В тот момент, когда ваша кодовая база поддерживает необходимый API (имеет вызовы командной строки или протокола IPC для желаемой функциональности, которые возвращают результаты по любому разумному механизму IPC) ... тогда ваш язык реализации панели мониторинга будет по существу произвольным.

Answer 7

Я бы избегал межязычных звонков, если это возможно; хрупкость и значительное увеличение зависимостей ждут вас на этом пути. Тем не менее, есть ...

Инлайн :: Python

Если нужно использовать python, то серия модулей Inline::* была в целом хорошо принята. Это позволяет вам писать Python внутри скрипта Perl. Вам все еще нужно написать Perl, но это позволит вам использовать библиотеки Python внутри сценариев Perl. Однако это затруднит отладку.