Гвидо ван Россум отвечает на вопросы

На прошлой неделе (19 августа — прим.пер.) у вас был шанс задать вопрос Гвидо ван Россуму, Великодушному Пожизненному Диктатору Python, касательно любых аспектов Python, а также его переезда в Dropbox. Гвидо не теряя времени ответил на некоторые ваши вопросы.

Из Google в Dropbox

от nurhussein
Привет. Что сподвигло вас перейти из Google в Dropbox? Чем вы занимались в Google, а что делаете сейчас в Dropbox?

Гвидо: После семи лет работы в Google я был готов к каким-либо изменениям в окружающей обстановке, и тут поступило предложение от Dropbox. По большому счету моя работа не сильно изменилась. Я всё ещё

• трачу 50% времени на то, что я обычно делаю согласно своей роли Великодушного Пожизненного Диктатора
• я обычный инженер в этой организации (не менеджер и даже не руковожу группой (не Team Leader))
• часто делаю инспекцию кода (code review), разрабатываю архитектуру и дизайн
• разбираю много электронных писем
• пишу код на Python

Детали работы конечно отличаются. Фактически в Google я делал две вещи: по началу два года я работал над первым online инструментом инспекции кода (code review) Mondrian, которая хоть и не была open source, но породила Rietveld. Сейчас Rietveld используется в проектах Pyhon, Go и Chromium. После этого я присоединился к Google App Engine, где занимался множеством разных вещей, в основном касающихся Python. Моим последним большим проектом была новый Python API для базы данных, NDB.
В компании Dropbox я работаю уже 7 месяцев и моим первым проектом был дизайн Dropbox Datastore API. По иронии судьбы (я не виноват) здесь тоже присутствует слово «datastore». Есть общие черты у Dropbox Datastore и Google App Engine Datastore.
Ещё одна забавная деталь. Несмотря на то, что большую часть дизайна придумано мною, и я написал два прототипа на Python, выпущенные в прошлом месяце SDK поддерживают только Java, Objective-C и JavaScript. Но я работаю над этим. Просто из-за этого интервью процесс идёт не так быстро 🙂

Почему Python избегает некоторых идиом ООП, присутствующих в других языках?

от i_ate_god (этот ник оскорбляет чувства верующих — прим. пер.)
Интерфейсы, абстрактные классы, приватные члены, др… Почему в Python отсутствуют эти вещи?

Гвидо: Я вижу две причины: (а) они вам в действительности не нужны, и (б) их сложно реализовать, так как отсутствует проверка типов на этапе компиляции. Python начинался как экспериментальный проект (не утверждённый или одобренный начальством, но и не запрещённый), и я хотел быстро получить рабочий прототип. Поэтому я убрал возможности, которые были не особо нужны и которые можно отложить; также пришлось все проверки типов делать в run time. Отсюда вытекают естественные ограничения на те возможности, которые поддерживает Python. Я также не был религиозным фанатом объектно ориентированного подхода. Я хотел получить простой язык, а объектно ориентированным он стал скорее по случайному стечению обстоятельств.
В последних версиях Python появились приблизительные аналоги тех вещей, о которых вы спрашиваете. Но они не всегда работают, как вы ожидаете, или могут приводить к лишним накладным расходам. Поэтому часто их стараются избегать, но есть и свои фанаты таких подходов.

Функциональное программирование

от ebno-10db (кто ему ник придумывал? — прим. пер.)
Некоторые люди утверждают, что Python хотя бы частично, но функциональный язык. Насколько я вижу, вы с этим не согласны. Функций map и filter недостаточно, чтобы язык стал функциональным. Насколько я знаю, эти функции добавил в язык Lisp разработчик, тоскующий по родному дому. И вы несколько раз порывались их убрать. Похоже что вы не фанат функциональной парадигмы, по крайней мере в Python.

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

Гвидо: Я не люблю делать выбор в пользу той или иной идеи исходя из религиозных предпочтений, и я пытаюсь быть прагматичным в выборе дизайна (но не сильно прагматичным, см. начало предложения :-). Я ценю читаемость и полезность реального кода. Бывают ситуации, когда map() и filter() очень полезны, а для остальных случаев существуют списковые выражения (list comprehensions). Я возненавидел reduce(), потому что эту функцию почти всегда использовали для двух вещей: (а) чтобы подсчитать сумму элементов и (б) чтобы написать нечитаемый код. Поэтому мы добавили встроенную функцию sum() и перевели reduce() из встроенных функций в модуль functools (это такая свалка для всяких ненужных мне вещей :-).
Когда я размышляю о функциональных языках программирования, я в основном думаю о языках с невероятно мощным компилятором, таким как у Haskell. Для таких компиляторов функциональная парадигма очень полезна, так как предоставляет огромный массив возможностей по трансформации, включая параллелизацию. Но компилятор Python понятия не имеет о том, что означает ваш код. И это тоже полезно. Поэтому я не считаю, что есть смысл в добавлении «функциональных» примитивов в Python, потому что причины, по которым эти примитивы хорошо показали себя в функциональных языках, не подходят к языку Python. А ещё код из-за них становится крайне нечитабельным для людей не привыкших к функциональным языкам (а таких большинство среди программистов).
А ещё я считаю, что современный набор функциональных языков не готов к мейнстриму. Честно говоря, я мало знаю функциональных языков кроме Haskell. Но любой язык менее популярный чем Haskell наверняка менее применим на практике. И я не слышал о языках более популярных чем Haskell. Что касается Haskell, я считаю, что это отличный язык для испытания всевозможных идей в технологии компиляторов, но думаю, что его “чистота” всегда будет стоять на пути к широкому внедрению. Необходимость иметь дело с Монадами отпугнёт многих.
(Похожие комментарии относятся к Scala. Это наверное лучший пример объединения функциональной и объектно-ориентированной парадигм в одном языке. Но в результате нужно быть действительно умным, чтобы писать на нём.)

Многострочные лябды

от NeverWorker1 (ещё один пример странных ников — прим. пер.)

Одна из часто слышимых жалоб касательно Python — это ограничение на использование лямбд. А именно ограничение в одну строку и невозможность делать присваивания. Очевидно, что причиной этому является важная роль пробелов в Python (если я правильно понял ваш комментарий по этому поводу). Я много времени размышлял над возможным синтаксисом многострочных лямбд, и лучшее, что мне пришло в голову — это попытаться впихнуть некоторые неиспользуемые (или редко используемые) символы внутрь фигурных скобочек в стиле языка C. Но в лучшем случае это приведёт к неразберихе в коде. Можно ли сделать удобнее, и будут ли многострочные лямбды когда-нибудь добавлены?

Гвидо: Правда? Люди, которые задают вопросы на Slashdot, почти никогда о таком не упоминали. 🙂
Можно сделать удобнее — используйте ключевое слово ‘def’, чтобы определить обычную функцию в локальной области. Полученная функция будет храниться в локальной переменной и будет обладать точно такой же семантикой, как и лямбда. За исключением привязки к локальной переменной. Не вижу никаких синтаксических ограничений. Например, нет никакой семантической разницы между

def make_adder(n):   def adder(x):     return x + n   return adder 

и эквивалентной записью с использование лямбд:

def make_adder(n):   return lambda x: x + n 

(единственная разница состоит в том, что используя интроспекцию, на вопрос о своём имени лябда ответит пустой строкой '', вместо 'adder').
Andrew Koenig однажды заметил, что существует ситуация, в которой лябды гораздо удобнее функций. Если у вас есть большой список или словарь (например некий аналог switch) состоящий из большого числа лямбд, то потребуется создать много коротких функций, придумать им названия и использовать их в при составлении списка или словаря. Но в таком примере синтаксиса однострочных лямбд обычно достаточно. В крайнем случае вы всегда можете использовать 'def' перед созданием списка или словаря.

PyPy

от Btrot69
Как вы считаете, будущее за PyPy? Или вы всё ещё сомневаетесь, и почему?

Гвидо: Я всё ещё сомневаюсь по двум причинам: (а) у них пока нет (хорошей) поддержки Python 3, и (б) есть множество модулей (в стандартной библиотеке и сторонних), которые плохо поддерживаются в PyPy. Но я надеюсь, что они исправят эти проблемы. Я считаю, что конкуренция с PyPy, Jython и IronPython помогает CPython двигаться вперёд.

Python в браузере?

от Btrot69
В течение нескольких лет были предприняты различные попытки создать Python в песочнице, который можно будет безопасно запускать внутри веб-браузера. В основном таким путём люди пытались исправить проблемы JavaScript. Теперь, когда JavaScript работает — и есть такие классные вещи, как CoffeeScript — можно прекратить вставлять Python в браузер?

Гвидо: Я перестал этим заниматься в 1995. То есть, ответ — да. И пожалуйста, не пытайтесь скомпилировать Python в JavaScript. У этих языков очень разная семантика. В итоге вам придётся реализовывать большую часть языка Python на JavaScript. Что, в свою очередь, ударит по производительности. (Сила CoffeeScript в том, что он изначально разрабатывался, чтобы быть скомпилированным в JavaScript. А сейчас оба эти языка развиваются в одном ключе, облегчая процесс компиляции.)

Python 3

от MetalliQaZ
Как вы оцениваете текущее положение дел с миграцией на Python 3? С точки зрения пользователя, переход основных популярных библиотек сильно затягивается, что в свою очередь затрудняет переезд на Python 3. В своей профессиональной деятельности я часто сталкиваюсь с отстутствием Python 3.x почти на всех системах. Даже версия 2.7 всё ещё редкость. Интересно услышать ваше мнение.

Гвидо: Интересно, где вы работаете. Я согласен, что миграция на Python 3 требует много времени, но если в вашей системе отсутствует Python 2.7, но вы наверное застряли в каменном веке. Когда я покидал Google, они почти закончили внутренний переход на Python 2.7 (предыдущая миграция с 2.4 на 2.6 успешно прошла несколько лет назад). Здесь в Dropbox и клиент, и сервер используют Python 2.7. Обе компании уже думают о Python 3.
Возвращаясь к миграции на Python 3, Я на самом деле большой оптимист. Большинство популярных библиотек уже имеют работающий порт на Py3k или занимаются портированием. (В свою очередь Python Software Foundation финансирует портирование проектов, которые широко используются, но не имеют сообщества, достаточного для подготовки порта). На это уйдёт много времени, но я вижу свет в конце тоннеля. Думаю через несколько лет большинство нового кода будет на Python 3. Чтобы полностью избавиться от использования Python 2 понадобится гораздо больше времени. Опять же, Windows XP до сих пор жив 🙂

Ключевой вопрос любому дизайнеру языка

от dkleinsc
Как изменились перспективы Python после того, как вы отрастили бороду? Насколько успех языка коррелирует с длиной бороды?

Гвидо: Борода абсолютно необходима. Посмотрите на судьбу Perl — всё дело в идеальном бритье Ларри Уолла (Larry Wall). 🙂

От переводчика

Я с удовольствием переводил интервью с Великодушным Пожизненным Диктатором. В его ответах мало воды и размышлений на отвлечённые темы. Он прагматично смотрит на Python, ценит практичность, читабельность и эффективность. Жаль, что прошло время, когда можно было задавать вопросы. А то Я бы спросил: «Когда появится JIT компиляция в Python?» На сегодняшний день производительность Python кода уступает Java, Ruby.