LXF100-101:Интервью LXF

Материал из Linuxformat.

Великий диктатор

«Великодушный пожизненный диктатор» сообщества Python и разработчик Google Гвидо ван Россум, продолжая надзирать за процессом разработки Python 3000, милостиво назначил аудиенцию Грэму Моррисону…

Голландский программист, работающий в Google с 2005 года, Гвидо ван Россум [Guido van Rossum] помимо всеобщего восхищения, в 2001 году получил Премию FSF за продвижение свободного ПО, а также был признан Выдающимся инженером Ассоциацией Вычислительной Техники в 2006.

Недавно на OScon Linux Format прервал его ланч, чтобы расспросить о проекте Python 3000, который сосредоточился на удалении дублированных модулей и конструкций из языка Python, чтобы реализовать подход «Один и только один очевидный способ сделать это», нарушая, однако, обратную совместимость с Python 2.x. Окончательный релиз запланирован на август 2008 года.

Linux Format: Как вы попали на работу в Google?

Гвидо ван Россум: Google долго пытался меня заманить. Первое приглашение последовало на OScon четыре года назад; я тогда как раз пообещал перебраться в Калифорнию и начать работу в небольшой только что учрежденной фирме, так что время они выбрали неудачно! А потом к ним начали присоединяться разные люди из сообщества Python, и все они мне рассказывали, какое это прекрасное место работы.

LXF: Потому что Google активно использует Python?

ГвР: Здесь здорово работать и без всякого Python’а! Многие из тех, кого я знал по Python, выполняют немалое количество разработок на Java.

LXF: А Google оплачивает вашу работу над Python?

ГвР: Да. Половину своего времени я трачу на работу с сообществом Python – например, эта конференция, разработка Python 3000 и т.д. А вторую половину я трачу на использование Python для разработки внутренних приложений Google. Это большое удовольствие. В Google очень богатый выбор работы – здесь масса интересных задач.

LXF: Изменился ли ваш подход к языку в целом — и к Python 3000 в частности — из-за того, что вы использовали этот язык в такой среде?

ГвР: Не совсем. Меня даже можно обвинить в том, что я слишком прислушиваюсь к внутренним жалобам в Google насчет реализации Python, когда проблема связана с тем, как Google использует Python, или как его устанавливает, или как применяет этот язык. По большому счету, Python не используется в крупных, публичных проектах Google, предназначенных для всего мира. Его использует подсайт http://code.google.com. Но Google очень активно применяет Python для исследований и управления системой.

LXF: Почему Google выбрал Python? Может, какой-то ведущий разработчик испытывал к нему особую страсть? Или…

ГвР: Не знаю! Возможно, этот выбор сделал кто-то из самых первых работников. Определенно имеется стандартизация Python – если вам надо написать скрипт, вы пишете его на Python. Сейчас много используется и Perl, и Ruby. Конечно же – тысячи скриптов оболочки, но множество крупных внутренних систем реализованы на Python.

LXF: И как же произойдет переход на Python 3000, если Google так активно использует Python?

ГвР: Медленно… Как Google его использует, это не главное! Крупные предприятия, как правило, любят использовать новые технологии не раньше, чем эти технологии хоть чуть-чуть созреют!

LXF: В своем выступлении вы говорили, что не обязательно начинать с чистого листа при переходе с одной версии на другую. Причина тому кроется в хорошем проектном решении или в том, что Python — язык особый?

ГвР: Трудно сказать… Я думаю, во многом это связано с самой природой сообщества. Perl продемонстрировал, что в его сообществе имеется солидная поддержка полного редизайна; причиной тому послужили долгие годы опыта работы с Perl и тот вывод, что кое-что явно нуждается в пересмотре.

Python на самом деле намного меньше, чем Perl – здесь намного больше библиотек и намного меньше языка; а P3000 скорее фокусируется на языке, чем на библиотеках. Очевидно, будет стандартная подчистка, новая библиотека ввода/вывода, но исключительно в рамках языка – и весьма интенсивно.

LXF: А в чем будет основное различие?

ГвР: Если меня никто не убедит внести еще какую-нибудь радикально новую функцию, я полагаю, что самым большим отличием станут строковые переменные Unicode.

LXF: Почему поддержка Unicode заняла так много времени?

ГвР: Вообще-то Unicode у нас есть; его ввели в 1999-м – а первый релиз с поддержкой вышел в 2000 году. В то время у нас были связаны руки: большинству пользователей Unicode был не нужен, и им не хотелось никаких перемен. Чтобы добавить Unicode в качестве отдельного типа данных, нам пришлось поддерживать конверсии и строковые объекты. Мы также вставили несколько конверсий по умолчанию; например, если у вас есть 8-битная строковая переменная, и вы приписываете ее к строковой переменной Unicode, то, если не выполнены определенные условия, в результате получится ошибка.

LXF: Означает ли акцент на Unicode, что сообщество изменилось?

ГвР: У нас очень прибавилось пользователей и членов сообщества в таких местах, как азиатские страны, для которых Unicode куда важнее. В Европе многие пользователи просто обходятся локалью Latin-1, они могут считать, что символы и байты – это одно и то же, и благодаря волшебству, совершаемому переменными среды в большинстве случаев, при печати этих объектов происходит именно то, что и должно происходить.

Нажим стал больше – всемирная паутина изменилась, потому что у web-сайтов появилось намного больше причин поддерживать разные языки: сама идея локали – скорее белый слон. Концепция локали появилась в стандарте С в 1989 году, это глобальная настройка, которая гласит: «Все, что я делаю со своими символами, я делаю в соответствии с определенным набором правил для кодирования», и она влияет на то, в каком формате обозначаются деньги, числа, символы и т.д. Она влияет на значение верхнего и нижнего регистра и то, как вы интерпретируете нижнюю половину кодовой таблицы 8-битных не-ASCII символов – то ли это кириллица, то ли буквы с диакритическими знаками и т.п.

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

LXF: Это уж хакерство!

ГвР: Да. Пользователю Интернет такая модель ни к чему – вы не можете ожидать, что все ваши пользователи используют одни и те же кодовые таблицы, если ваш сайт не сугубо местный.

Некоторые каркасы Python обладают мощной поддержкой интернационализации, активно использующей Unicode, особенно вышедшие за последние шесть лет: взаимопонимание улучшилось. Раньше подавляющее большинство совершенно не понимали кодирования символов и путали байты и кодовые точки (code point), когда речь шла о символах… В чем разница? Народ медленно, но верно обучился пользоваться существующими возможностями Unicode…

Емкость запоминающих устройств чудовищно возросла, и изначальный подход «если мы перейдем на Unicode, наши программы будут потреблять вдвое больше памяти» уже не так актуален, как раньше. Многие платформы усовершенствовали поддержу Unicode, облегчив нам жизнь. Web-браузеры в наши дни очень неплохо поддерживают разные языки и Unicode. Но и приложения на одной платформе тоже совершенствуются с каждым новым релизом.

LXF: Будет ли существующая Unicode-реализация совместима с новым подходом?

ГвР: Она совместима. В числе прочего в 2000 году мы сделали поведение объектов Unicode – насколько это было возможно – логически связанным с поведением 8-битных строковых переменных. Строковые объекты обоих видов обладают большим количеством методов для производства с ними различных действий: поиска, подсчета, конверсии, связывания слов. Все эти методы определяются идентично для 8-битных строк и для Unicode-строк, и если вы сейчас пишете программу, содержащую текстовые или буквенные данные, и производите обработку текста, даже сегодня один и тот же код будет работать с Unicode. Неопределенность возникает, если вы начинаете конвертировать Unicode, скажем, в UTF-8 или UCS-2, и записывать в файл. Я рассчитываю, что нам удастся получить в основном совместимые API для файловых объектов при обработке текста.

LXF: Именно об этом вы говорили раньше.

ГвР: Я рассчитываю на простой случай, когда вы открываете файл, просто задав имя файла (что по умолчанию создает вам текстовый файл), и затем проход по строкам этого файла будет вести себя точно так же, как ведет себя сейчас: программа будет видеть, что каждая строка – это строковая переменная Unicode, и файл может быть кодирован в UTF-8, что покамест не поддерживается, однако пользователь совершенно не заметит разницы.

LXF: Над чем лично вы сейчас работаете?

ГвР: Планирую написать стандартную библиотеку ввода-вывода, используя байты и объекты Unicode, по минимуму используя код на С, и проделать большую часть работы касательно буферизации и кодирования, которую я упоминал в своем выступлении о Python. Но при этом сделать ее скорее библиотечным модулем, а не стандартным способом открытия файлов; затем я смогу все это смонтировать, чтобы в некий момент встроенная функция Open вернула объект совершенно другого вида; а потом наступит очередь тестирования и выявления неполадок; надеюсь, большинство проблем решится достаточно быстро.

LXF: Каким образом вы делите задачи? Вы отводите определенную часть сообществу или они сами решают, над чем им интересно работать?

ГвР: Когда мы делали 2.5, у нас была основная группа разработчиков, которые распределяли работу между собой. Это итеративный процесс: мы определяем сферу работы, вносим изменения, проводим ряд тестов для регрессионного анализа… Потом снова намылить, смыть – пока все не заработает, как надо, тогда можно двигаться дальше.

LXF: Как продвигается работа над интерпретатором?

ГвР: Это большой проект – надеюсь, он будет завершен где-то через полгода… Мы уже почти год над ним работаем, и я оптимистично считаю, что мы движемся в верном направлении. LXF