Возникла необходимость решить следующую проблему: как обмениваться данными между разными интерпретаторами Python?! Я нашел несколько решений, но хочу рассказать об одном, на мой взгляд, самом удобном.
Выбор подхода
Для начала я постарался выбрать самое удобное решение из множества.Возможно не корректно сравнивать очередь сообщений, сокеты и RPC, но я исходил из задачи.
Вот что доступно:
TCP-сокеты
Использование сокетов — самый простой способ взаимодействия; передавать можно любые данные, но код придется наполнять реализацией собственного протокола.Этот путь тернист, и ошибки неизбежны.
Вывод: подходит, но сложно.
Библиотека ZeroMQ
Очень многообещающая разработка очереди сообщений без брокера.Реализовано как библиотека pyzmq И pyzmq-статический .
В первом случае вам необходимо установить сам ZeroMQ — общую библиотеку, написанную на C. Второй уже содержит бинарный файл.
Все начиналось довольно забавно, код работал нормально, пока я не перешел на IronPython. Для IronPython pyzmq не реализован, но это не проблема, есть интеграция .
NET, которая позволяет использовать clrzmq — привязка для .
NET; и тут начались проблемы.
Бинарник доступен через плагин для VisualStudio — nuget, поэтому мне пришлось скомпилировать библиотеку.
Скачал исходники, там все удобно, скрипт собирается командой build, но не все так просто.
Версия 2 вообще не собиралась, хотя зависимости разрешались корректно через nuget (может я взял битый коммит?), бета 3 собиралась, но крашилась даже на примере из туториала) В итоге я нашел в сети бинарник 2, но он меня совершенно не порадовал.
Все работало, но API в 3 поменялось настолько, что переписывать код по сто раз не хотелось.
Вывод: хорошо, но сыровато за пределами чистого Python.
Поджигатель, подожги его!
Сначала решил добить 0mq, но вспомнил о существовании такой библиотеки как Поджигатель : библиотека из кризисных 90-х, которая хорошо себя чувствует и развивается.Я не буду перечислять все его преимущества; сейчас меня интересует только одно – взаимодействие переводчиков.
Давайте перейдем непосредственно к делу, давайте попробуем пример из руководство , но с той разницей, что запускаем всё под разными интерпретаторами (код не менял, просто ввёл свой никнейм).
Запускаем нейм-сервер под Jython, кстати, это первый огромный плюс, у 0mq нейм-сервер еще не доделан: 
Ух ты! Началось.
Теперь регистрируем сервер, на котором будет работать IronPython: 
Регистрация прошла успешно.
Следующий шаг — запуск клиента.
Делаем это с помощью классического Python (их у меня сразу много, но я запускал EPD): 
Замечательный! Все работало.
маринованная версия
Как вариант, я также попробовал запустить одну из частей под Python 3. Без хака не получилось :( Последний использует Pickle версии 3 + отсутствуют (удалены, перемещены) некоторые стандартные модули, хотя такое поведение может быть Но основная причина в том, что Pyro4 использует для сериализации Pickle, причем последнюю версию.Вот как нам удалось обойти этот недостаток и подключить Python 3 к IronPython 2 и Jython 2:
Это необходимо добавить в клиентский код перед импортом Pyro. Все работало:import pickle pickle.HIGHEST_PROTOCOL = 2
Обратите внимание на использование 64-битного Python 3 вместе с двойками.
Кстати, как вариант, можно воспользоваться библиотекой пиролит для прямого подключения из .
NET или Java без интерпретатора Python. На самом деле это мини-огурчик.
В целом решение с Pyro мне пока понравилось больше других, но если система содержит много компонентов разных версий, то, наверное, выгоднее будет использовать 0mq. Хотя я пока остановлюсь на Pyro4. Теги: #python #IronPython #jython #межпроцессное взаимодействие #.
NET #java #python
-
Как Попасть В Поисковые Системы В 2004 Году
19 Oct, 24 -
3D-Печать Песком С Использованием Солнца
19 Oct, 24 -
Мысли Дизайнера О Разработке Для Ipad
19 Oct, 24 -
Как Работает Один Python-Разработчик
19 Oct, 24
