Fork me on GitHub
13/8/2006

Фил Томпсон о PyQt

Перевод интервью KDE Dot News с Филом Томпсоном, автором PyQt.

Интервью брал Джонатан Райделл, 08.08.2006

Языки программирования высокого уровня чаще используются в настольном ПО, чем C и C++. Один из таких языков, имеющий наилучшую поддержку KDE и Qt - Python. Об истории и текущем положении PyQt KDE Dot News спрашивает у автора PyQt - Фила Томпсона.

Пожалуйста, представьтесь и расскажите о Вашем вкладе в Свободное ПО

Моя компания, Riverbank Computing, разрабатывает и поддерживает несколько пакетов. Это SIP, PyQt и QScintilla.

SIP - это генератор Python-привязок (bindings) для C и C++ библиотек. Он начинался как "небольшой SWIG" (отсюда и имя) и первый релиз был выпущен в 1998. Со временем я понял, что SWIG, как более общий инструмент, не очень хорош для создания Python-привязок для C++. Так что SIP обозначился как специализированный инструмент.

PyQt - Python-привязки для Qt. PyQt3 поддерживает Qt версий с 1 по 3. PyQt4 поддерживает Qt 4-ой версии. Первый релиз был в том же 1998, хотя изначально назывался PyKDE. PyQt написан с использованием SIP. PyQt следует модели лицензирования Trolltech и существует в двух версиях: коммерческой и GPL.

Что такое PyQt и каковы причины его использовать?

PyQt дает Python-программисту доступ ко всему Qt API. При помощи Python можно делать практически все вещи, что и с помощью C++.

Поскольку у C++ и Python одинаковый API, то вопрос "почему следует использовать его" выходит за рамки выбора языка программирования и не специфичен для PyQt. Для меня преимущество Python перед C++ как прикладного языка программирования просто в производительности программиста. Вы можете глянуть стандартные примеры, портированные на PyQt. Они имеют те же функции и используют тот же API, но в Python-версиях на 50-60% меньше строк кода и такой код легче читать.

Относительно производительности - Python легко изучается, но его возможностей достаточно и более опытным программистам. Trolltech открыл для себя, что PyQt позволяет продавать Qt в высокотехнологичные предприятия, где пользователи - узкие специалисты (химики, инженеры), а не C++-программисты.

И, конечно, PyQt - зрелый и стабильный продукт, имеющий широкую пользовательскую базу. Основные отзывы, которые я получал от пользователей, это "просто работает" и "классно".

Почему Вы начали писать PyQt?

Обычная причина - руки чесались. Я использовал Tcl и Tk несколько лет в разработке персональных инструментов для повышения производительности и был разочарован насколько все более визуально страшными становятся Tk-приложения (потому что всё остальное становилось приятней). Я начал использовать KDE и переключился на Python, потому что написал несколько привязок к KDE с использованием SWIG. Вскоре я осознал, что я могу сделать лучше, и начал всё заново.

Версия 0.1 была выпущена 1-го ноября 1998 и использовала Qt 1.41 и KDE 1.0. С тех пор релизы выходили примерно каждые три месяца.

Как реализованы привязки?

SIP берет набор инструкций (.sip файлы), описывающих API и генерирует требуемый C++ код. Потом он компилируется и на выходе получается модуль Python. Фактически, файлы .sip - файлы заголовков класса, у которых кое-что убрано (потому что SIP не включается полный C++-парсер) и кое-что добавлено (поскольку C++ не несет достаточной информации о работе API).

Один из ключей к успеху PyQt - внимание к деталям в .sip файлах. Я не верю, что можно автоматизировать создание привязок и в итоге получить нечто промышленно значимое. Вы можете автоматизировать 95% работы, но все равно должны "пройтись" по API и добавить дополнительную информацию, необходимую данному конкретному языку. С Python, например: важно, что Python-объекты должны знать, нужно ли им вызывать соответствующий деструктор C++-объекта при сборке мусора. Ожидание, что программист будет сам решать этот вопрос - путь к coredump.

В PyQt3 .sip файлы были сделаны вручную - они постоянно развивались, начиная с оригинальных, созданных для Qt 1.41. SIP содержит систему версий, так что .sip фалы 3-ей версии содержат полную историю Qt API с 1.41 до 3.3.6. Хотя я не тестировал, PyQt3 по идее, должен собираться с Qt 1.

Для PyQt4 я использовал внутренний инструмент (написанный на PyQt, разумеется), называемый metasip. Это своего рода IDE для SIP. Он использует GCC-XML для разбора заголовочных файлов последней версии и сохраняет релевантные данные в XML, в metasip-проект. metasip далее делает некое подобие diff с предыдущей версией API и отмечает все изменения, которые необходимо просмотреть. После, список изменений генерируется при помощи GUI и автоматически заносится в TODO. Создание .sip файлов - просто нажатие на кнопку. В моем subversion-репозитории PyQt4 - это XML файл, размером примерно 20 Мб. Обновление PyQt4 для младшей версии Qt 4 (т.е. с x.y1.z2 на x.y2.z2) - работа на полчаса.

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

Python-класс реализует методы, эквивалентные C++-реализации. Поскольку Python не поддерживает перегрузку функции, то корректная сигнатура определяется во время запуска по типу передаваемых аргументов.

Если C++-класс содержит виртуальные функции, то SIP создает C++-подкласс с кодом, заново реализующим эти виртуалы и затем проверяет, существует ли соответствующая Python-реализация. Если так, то вызывается она; если же нет то вызывается базовая реализация. Результат проверки кешируется, так что ощутимых накладных расходов нет. Доступ к защищенным функциям также реализуется через генерируемый подкласс.

А если сравнить привязки, реализуемые с SMOKE?

Я не знаю. Я никогда не использовал ни сам SMOKE, ни привязки, основанные на нем.

Насколько полны привязки PyQt3?

Они полны уже несколько лет. Новые релизы PyQt содержат небольшие обновления, диктуемые изменениями в Qt и изменения инфраструктуры, диктуемые новыми версиями SIP.

Я очень рано пришел к выводу, что не могу решить, какая часть Qt API должна быть предоставлена Python-программисту, так что я предоставляю весь API целиком.

Каково состояние привязок к Qt4?

Полны и стабильны. PyQt 4.0 был выпущен 10 июня после 6 месяцев снапшотов для разработчиков. PyQt 4.0.1 был выпущен 15 июля - это всего лишь небольшое обновление - не было информации ни об одной ошибки в самом PyQt.

Ваше мнение насчет PyKDE?

Как оригинальный автор говорю - замечательно. У Джима Баблица, текущего сопровождающего, гораздо более тяжелая работа чем у меня с PyQt. KDE гораздо больше, чем Qt, API менее согласован, дистрибутивы [Linux] более заинтересованы в "игре" с KDE, а не Qt, и вдобавок, он общается со мной по поводу улучшения SIP, когда я "ломаю" его. Так что Джим гораздо более приятный человек, чем я.

Я полагаю, что он сможет получать больше помощи, когда сделает PyKDE4, чем сейчас. Возможно, дистрибутивы [Linux], широко использующие PyKDE, возьмут на себя ответственность (кхе-кхе).

Какие контакты у Вас были по работе с Trolltech?

К нас были постоянные, неформальные отношения 5 или 6 лет. Они были настолько любезны, что пару лет назад пригласили меня в Осло. Было интересно посмотреть на их разработку. Что интересно, они были (и сейчас, конечно, остаются) сфокусированы на технологичность, без сильной поддержки маркетинга. Как компания они не "берут" PyQt, поскольку не понимают, зачем кому-то использовать что-то кроме C++. И я полагаю, большинство их программистов и сейчас так считают.

Тем не менее, в наши дни влияние маркетинга гораздо сильнее. Они знают, что люди хотят использовать другие языки, потому что их клиенты говорят об этом. Они знают, что есть крупные корпорации, желающие купить Qt только потому, что они хотят использовать PyQt.

Они даже предпринимают усилия в развитие Qt-экосистемы: партнерские программы с компаниями наподобие Riverbank, разрабатывающими родственные технологии.

Как эта работа финансируется?

PyQt дает прибыль - он сам себя финансирует. Это не только продажа лицензий, это также сопутствующая работа. Например, в конце года я работал с клиентом на расширение использования PyQt внутри его организации.

Сколько у Вас коммерческих пользователей?

На данный момент - около 200.

Можете назвать некоторых, наиболее интересных, пользователей PyQt?

Один из недостатков продажи ПО "человеком-оркестром" (по-видимому, подразумевается, что программист и менеджер - одно лицо - прим. pythy) в том, что ты не знаешь своих клиентов в достаточной мере. Единственно, я с гордостью могу сказать, что я фанат кино и что Disney, Dreamworks, Pixar, Industrial Light and Magic и Sony Pictures - коммерческие пользователи PyQt.

Сколько людей работает над PyQt?

Только я работаю над SIP и основными привязками, не считая некоторых патчей "со стороны". Для PyQt4 Торстен Марек написал pyuic4. Улли Бернинг оказал неоценимую помощь в сборке PyQt на HP-UX, AIX и Solaris.

И кончено, удачный проект - гораздо больше чем просто люди, пишущие код, это люди, внесшие вклад в сообщество. Большое спасибо Детлеву и Джиму, о котором я уже говорил; Бодуэну за великолепную книгу; группе, портировавшей примеры на PyQt4; Жерарду за PyQwt; Дэвиду и Андреасу за их качественную поддержку в почтовом списке рассылки.

Чем еще занимается Riverbank?

Другая экспертная область - встраиваемые Linux-системы - портирование, драйверы устройств и т.д. Моей первой работой после окончания университета была работа инженера, так что я всегда любил проекты, где результат можно "пощупать".

Хотелось бы Вам, чтобы больше программистов использовало языки высокого уровня?

Да, я думаю это неизбежно. Во времена моей молодости шумели дебаты о том, на чем нужно писать программы для CP/M на Z80-ассемблере или на C. C-программы занимали больше ресурсов (я уже говорил об этом), но все мои C-программы были более функциональны, содержали меньше ошибок и были быстрее написаны, чем Z80-программы. Я встречаю много споров по поводу использования C++ и таких языков как Python (или Ruby, например) - эти споры аналогичны давним. На данный момент C++ хорош для написания каркасов (framework), но я предпочитаю не использовать его для создания приложения.

Вы посетите Akademy в этом году?

Нет, боюсь я слишком занят.

Комментарии

Все статьи