Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Журнал ВРМ World

Очаровательный Python: взгляд изнутри на JPython и Python for .NET (интервью с его создателями)

Дэйвид Мертц (David Mertz) беседует с Марком Хэммондом (Mark Hammond), Финном Боком (Finn Bock) и Бaрри Уорсо (Barry Warsaw), разработчиками JPython и Python for .NET. Это интервью позволяет взглянуть на развитие фирмы Microsoft глазами Марка Хэммонда (разумеется, в рамках условий его контракта о неразглашении конфиденциальной информации) и отражает текущее состояние дел в работе Финна Бока и Барри Уорсо над близким к своему завершению проектом JPyhton.

Несмотря на то, что под языком Python обычно подразумевается CPython, его спецификация была реализована еще на нескольких платформах, включая приложения для Java и .NET. JPython компилирует тексты Python в байт-код Java и обеспечивает прозрачный доступ к Java-классам. Python for .NET представляет собой приложение на готовящейся к выпуску межъязыковой платформе компании Microsoft. В процессе своего разговора с Марком Хэммондом, Финном Боком и Барри Уорсо я многое узнал о том, как были разработаны JPython и Python for .NET, а также каково будущее этих альтернативных реализаций языка Python.

Python for .NET

Марк Хэммонд знаком большинству программистов Python по своей великолепной разработке среды PythonWin и расширений PythonCOM. По тем же причинам, по которым мы выбрали Марка, он был выбран и фирмой Microsoft. Они приняли решение обратиться к нему за помощью в реализации Python for .NET. Марк утверждает, что рабочая версия Python for .NET уже на подходе и вы уже можете получить альфа или бета версию на ActiveState.


Дэвид Мертц: Что же все-таки представляет собой Python for .NET? Наверное, больше всего меня интересует, как Python for .NET связан с вашими собственными расширениями для CPython - PythonWin и PythonCOM, которые уже давно имеют доступ к внутренним структурам Windows.

Марк Хэммонд: Python for .NET является компилятором и средой выполнения, реализующей Python на платформе Microsoft .NET. Платформа .NET обеспечивает среду выполнения и систему метаданных, спроектированные для осуществления полнофункционального межъязыкового взаимодействия, но для этого языки должны работать именно в этой среде.

Например, если класс Python делается общедоступным, с тем, чтобы программист, пишущий на Visual Basic, мог использовать его преимущества, то класс Python должен быть реализован и описан в терминах .NET, а не CPython.

Преимущество Python for .NET просто в том, что вы можете взаимодействовать со средой .NET. В нем все еще имеется множество недостатков, в основном из-за несовершенства реализации. Но это на самом деле только вопрос времени. Мы все еще находимся на стадии бета-версии в части разработки и отладки.

Мертц: Как вы думаете, в чем сейчас заключается несовместимость Python for .NET и CPython?

Хэммонд: Ну, большинство модулей еще не реализованы, а существующие написанные на Си модули не могут использоваться. Если вашей целью не является среда .NET, возможно, вы не захотите использовать Python for .NET на этом этапе.

Мертц: Однако у Python for .NET существуют и явные достоинства, например, простота межъязыкового сообщения и разработки многоязычных приложений. Но на основании чего вы могли бы (разумеется, гипотетически) оценить его как нечто лучшее, чем то, что уже существует - например, Python+C+SWIG?

Хэммонд: В общем-то, что касается Python+C+SWIG, это должно быть очевидно. В любом другом случае межъязыковые вызовы будут гораздо легче, чем между этими языками. Но в других отношениях SWIG представляет собой отличный продукт. Он перевел написание на Python расширений для Си из области черной магии в разряд обычной достаточно сложной работы!

Сравнение .NET с COM или Corba более рационально. И COM и Corba предлагают решение, в котором межъязыковые вызовы "просто работают", не требуя ручного труда или компиляции. .NET пошел немного дальше, предложив, среди прочего, возможности для межъязыкового наследования и исключений. Эти преимущества очень схожи с теми, с которыми вы столкнулись бы в многоязыковых реализациях под Java Virtual Machine.

Мертц: Pyhton for .NET компилирует скрипты Python в формат внешней виртуальной машины. У вас есть какие-нибудь предварительные предположения о том, будет ли поддерживать .NET VM некоторые экзотические возможности Stackless Python и Vyper - такие, как продолжения, генераторы, сопрограммы, хвостовые рекурсии или отложенные вычисления?

Хэммонд: Да, теоретически будет. Но условия соглашения Microsoft Beta не позволяют мне обсуждать его функциональные возможности. Скажем так: мы еще только будем стремиться к реализации характеристик, описанных в основном справочнике по языку Python. "Сборка мусора" является в этом случае неотъемлемой составляющей, аналогично JPython и различным JVM.

Мертц: Переходя к теме политики, как вы считаете, почему Microsoft работает над разработкой Python for .NET?

Хэммонд: Потому, что люди, выбравшие в качестве направления .NET, могут реализовать свои планы с помощью Python. Microsoft обеспечил себе использование языка Python и множество других языков еще вначале разработки, чтобы иметь уверенность, что их VM действительно не зависит от языка. Сегодня они внесли в VM ряд изменений на основе информации, полученной от разработчиков, работающих с различными языками.

Мертц: И каковы их финансовые взаимоотношения с Python for .NET? Вы платите им? Или они платят вам?

Хэммонд: Мы с Грегом Стайном заключили контракт с Microsoft на создание Python for .NET. Условия контракта конфиденциальны. Однако, по сути я работаю в ActiveState (разработавшем Perl для реализации .NET). Я предполагаю, что для завершения проекта они подпишут аналогичный контракт с Microsoft.

Мертц: Как это отразится на лицензии Python for .NET?

Хэммонд: Python for .NET будет иметь пометку (c) "Microsoft", но совершенно точно будет бесплатным.

Мертц: Трудно не волноваться по поводу возможного использования компанией Microsoft частных расширений и дополнений в рамках известной стратегии "перехватить, развить, уничтожить". Другими словами, я боюсь, что Python for .NET в долговременной перспективе может оказаться не таким уж хорошей находкой для языка Python.

Хэммонд: Ну, если .NET станет серьезной силой, наличие реализации языка Python, ориентированной на нее, этому языку только поможет, почтит также, как JPython помог ему с JVM.

JPython

Барри Уорсо и Финн Бок являются на сегодняшний день самыми активными разработчиками JPython, хотя работа эта в действительности очень ориентирована на сообщество. К сожалению, Джим Хьюгунин, первый разработчиком JPython, больше не в состоянии активно работать с ним. Полная (и более технологичная) версия этого интервью находится здесь.


Дэвид Мертц: Что же представляет собой JPython?

Барри Уорсо: Я дам вам текст моего стандартного маркетингового заявления:

JPython - это 100% язык программирования Pure Java. Он позволяет полностью перевести исходный код языка Python в байт-код Java, и запустить полученный байт-код на любой Java Virtual Machine. Это совершенно незаметная и плавная интеграция с Java. Из Python вы можете получить доступ ко всем библиотекам Java, строить приложения, интегрироваться с Java bean и разбивать на подклассы Python классы Java, и наоборот. Аналогично языку Python и в отличие от Java, JPython может использоваться интерактивно; просто наберите некий код на JPython в строке приглашения и вы немедленно увидите результаты.

В более простых терминах, JPython позволяет вам составить скрипт для любого нужного вам Java-кода, переходящий при этом в код, который по количеству строк меньше исходного в два-десять раз. Поскольку Python является языком, с димамической типизацией, вы, к тому же, можете разрабатывать приложения быстрее и с меньшим количеством ошибок, получая в результате более гибкую программу.

Мертц: Как начиналась разработка JPython?

Уорсо: Вообще-то, JPython бы изобретен Джимом Хьюгунином, работающим в ориентированном на Xerox PARC программистском проекте. Зная Джима, я думаю, возможно в первую очередь его интересовала сложность задачи. Множество людей в мире Python даже не думали о том, что нечто подобное может быть реализовано. Сам Гвидо входил в число таких скептиков. А Джим доказал, что все они ошибались!

Так зачем же продолжать разработку JPython теперь, когда эта сложная задача уже решена? А затем, что это наиболее ценный инструмент Java из всех когда-либо известных программистам Java. До сих пор!

Мертц: как вы думаете, что стимулировало необходимость в JPython?

Уорсо: Для начала вам необходимо понять, что JPython не является конкурентом Java - это его великолепное дополнение. Java - статически типизированный, компилируемый язык. Это гарантирует типо-безопасность библиотек и более высокую скорость работы. Интересно, что, несмотря на то, что он представляет собой язык, интерпретируемый на базе байт-кода, большинство людей рассматривает Java как традиционную программу, подразумевающую стандартный цикл "написание кода - компиляция - запуск - редактирование". К тому же, Java безусловно занимает солидное положение в мире программного обеспечения, поэтому к услугам программиста, пишущего на Java, имеется множество ресурсов.

Но тот же статический контроль типов и традиционный цикл программирования увеличивает стоимость разработки приложений Java с точки зрения человеческих ресурсов. А Python превосходит его в этой области по всем параметрам. Поскольку Python такой простой и небольшой по размеру язык, он очень легок для изучения. Самые опытные программисты могут за день изучить его до необходимого для работы уровня. Кроме того, создание Python основывалось на идее о том, что код чаще приходится читать, а не писать. Поэтому исходный код Python прост для совместного использования в больших проектах.

Но что гораздо важнее, Python является очень высокоуровневым языком с динамическим контролем типов. Это выливается в значительную экономию на объемах кода, необходимых для выполнения некоторой задачи. Поскольку с помощью Python я могу написать меньше строк кода, я могу писать их быстрее и с меньшим числом ошибок. Это замечательно подходит для быстрой разработки приложений.

Python предлагает также интерактивный интерпретатор, что означает, что вы можете просто сесть перед экраном интерпретатора, импортировать в строку приглашения Java-код, создать примеры классов Java, сделать вызовы методов и т.д. - и все это интерактивно. Это отличный инструмент для обучения программистов использованию общих библиотек Java или для экспериментов с новыми Java API.

Но по моему мнению, все программисты должны иметь в арсенале и CPython и JPython.

Мертц: Какие преимущества JPython относительно CPython вы могли бы назвать?

Бок: JPython предоставляет полный доступ к лежащему в его основе языку реализации. В большинстве (возможно, во всех) скриптовых языках, основанных на Си, Си-функция должна быть окружена тонкой прослойкой кода, обслуживающего представление Си-функции в скриптовом языке, и для автоматизации создания этого кода существуют такие великолепные инструменты, как SWIG. А JPython не требует такой оболочки из кода. Весь когда-либо написанный код Java доступен в JPython, и эта интеграция идет в обоих направлениях. Классы и примеры, определенные в JPython, могут передаваться в код Java так же, как если бы они были изначально классами и примерами Java (чем они на самом деле и являются).

Встраиваемые/расширяемые API делают доступ к объектам JPython из приложений или модулей достаточно изящным. Частично эта красота идет от того, что JPython и Java оба являются объектно-ориентированными языками. Джим в значительной мере воспользовался этим преимуществом.

Уорсо: Чего не хватает CPython, так это доступа к безбрежному мировому океану кода Java. Если есть необходимые вам библиотеки Java, вам поможет JPython. Однако, у JPython, в свою очередь, отсутствует простой доступ к любой существующей в мире библиотеке Си. Финн проделал работу по интеграции таких средств, как Tkinter и модуль POSIX через JNI, но они всегда будут нестандартными в JPython, так как мы хотим сохранить 100% сертификацию Pure Java.

Мертц: И какие же слабые места JPython вы могли бы назвать?

Финн Бок: JPython предоставляет доступ только к коду Java, а не к любому из существующих модулей Си. Таким образом, каждый модуль Python, реализованный на Си, нуждается в повторной реализации на Java. А CPython имеет достаточно большое число модулей.

Кроме того, для встраиваемых/расширяемых API никакой другой документации, кроме исходного кода, нет.

Мертц: Можете ли вы назвать какие либо преимущества JPython по сравнению с чистым Java?

Уорсо: Я думаю, большую часть этого вопроса мы уже обсудили. Но давайте поговорим о проблемах функционирования JPython. Поскольку JPython реализует динамическую семантику Python, среда выполнения для JPython достаточно объемна. Это может повлиять на производительность некоторых приложений. Стандартные оптимизации Java - такие, как just-in-time компиляторы и технология Hotspot - могут значительно уменьшить такое влияние (сравнительное исследование, проведенное восемь месяцев назад, показало, что с помощью JVM, дополненной JIT, JPython 1.1 может приблизиться и даже превысить скорость работы CPython 1.5.2). Мы будем обновлять результаты этих исследований, сосредотачиваясь на вопросах функционирования после того, как начнем выпускать преемника JPython (подробнее об этом ниже).

Но по аналогии с CPython, вы всегда можете переписать критические для функционирования разделы вашего приложения на Java.

Мертц: Как выдумаете, насколько широко используется JPyhton?

Уорсо: Я считаю, что он получает все более широкое распространение. Люди находят, что это важно для достижения технологического успеха. JPython полезен для всех видов задач, от обеспечения доступной скриптовой среды для конечных пользователей до упрощения создания тестовых сред для библиотек и приложений Java. Самым большим препятствием для JPython на сегодняшний день является его недостаточная реклама. Я надеюсь, эта статья поможет в этом!

Мертц: Вы думаете, JPython является попыткой поддержать CPython?

Бок: Да. Непосредственно сейчас JPython пытается наверстать его. Почти все новые возможности сначала добавляются в CPython. (Хотя строковый модуль появился раньше в JPython). JPython находится здесь в менее выигрышном положении, поскольку у CPython в пятнадцать раз больше базовых разработчиков, чем у JPython. Но даже при всем при этом почти для всех новых возможностей, имеющихся в CPython 2.0, существует версия на JPython.

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

Уорсо: Я убежден, что на уровне языка JPython и CPython должны быть абсолютно совместимы. В случаях, когда это невозможно, Гвидо решает, являются ли эти различия результатом особенностей реализации или следствием имеющихся в ней ошибок. Я бы предпочел в итоге увидеть CPython и JPython равнозначными, чтобы JPython стимулировал развитие CPython в различных направлениях, и наоборот.

Одним из популярных примеров этого является поддержка Unicode. JPyhton уже полностью поддерживает его. Другой пример - двойственность типов/классов. В CPython у вас есть встроенные типы - такие, как строки, словари, списки и числа. У вас также есть классы и воплощения, но встроенные типы не могут наследоваться. И чтобы еще больше все усложнить, воплощение имеет и тип, и класс. Возможно, проще сначала привести все это в порядок в JPython, так как его реализация носит объектно-ориентированный характер.

Мертц: Как вы думаете, в чем заключаются несовместимость JPython и CPython?

Уорсо: Ну, существует множество маленьких различий в их работе. Все они отражены в документации по JPython. И также некоторые из них классифицируются как допустимые отличия, отражающие особенности языка, а некоторые указывают на те места, в которых та или иная реализация требует отладки. Большинство их достаточно несущественны.

Бок: Некоторые модули не были или не могут быть реализованы на JPython. Некоторые могут быть реализованы только как модули JNI и в этом качестве могут оказаться бесполезными для среды использования.

В действительности, когда я выпустил свой собственный скрипт и программы (вместе с IDLE, PySol и набором инструментов PMW), проблемы, с которыми я столкнулся, состояли не в случайных исправлениях "сборки мусора" или в методе missing_del_method. Они были маленькими вопросами, которыми никто до меня не занимался так, как поведением CPython.

Уорсо: Следующая версия JPython будет совместима с определением языка в Python 2.0, поэтому самые крупные проблемы будут сосредоточены в библиотеках. Любой из стандартных библиотечных модулей из дистрибутива CPython, написанный на чистом Python, должен быть переносимым. Модули расширений Си таковыми не будут, если только они не интегрированы специально через мост JNI или заново реализованы на Java. И любое приложение JPython, широко использующее различные Java API, будет иметь сложности с возвратом к CPython.

С другой стороны, в библиотеках этих двух систем есть много общего. Благоразумно будет встроить в ваше приложение слои совместимости.

Мертц: Какие-нибудь соображения относительно направлений развития JPython в будущем?

Уорсо: Вообще-то мы создали преемника JPython, "Jython", основанный на общедоступном релизе JPython 1.1. Мы сделали это, чтобы гарантировать долговечность и стабильность этого проекта. Это все уже было сделано применительно к лицензии CNRI для JPython 1.1.x. Мы перенесли весь процесс разработки в SourceForge, причем нам удалось сохранить тот же тип открытой разработки, что так удачно зарекомендовал себя в случае с CPython. Мы с Финном, разумеется, тесно вовлечены в перспективную разработку Jython, который должен быть выпущен с одобренной OSI лицензией CPython 2.0. Это как угодно близко к "официальной" ветви проекта, и поэтому сегодняшнее сообщество JPython должно осознавать, что Jython никогда никуда не исчезнет. Мы надеемся как раз, что это они перейдут на Jython.

Сейчас код все еще находится в альфа-версии, но мы с Финном будем работать над техническими версиями для релиза Jython 2.0, куда уже входит список опечаток Финна. CPython 2.0 имеет такие возможности, как расширенные присваивания и печать (с планируемыми к выпуску вложенными списками). Мы интегрировали бесплатный код Apache Jakarta OROMatcher, исключающий необходимость двойного лицензирования, и исправили множество ошибок. Я не знаю, когда выйдет первый альфа-релиз Jython 2.0, но весь код доступен сейчас в дереве SourceForge CVS.

Ресурсы: