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

Original author: samzenpus
  • Translation
На прошлой неделе (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.
Share post

Similar posts

Comments 40

    +11
    У Великодушного Пожизненного Диктатора хорошее чувство юмора!
      +21
      Переводчик, что у вас с ником?
        +10
        Это вполне нормальное имя для голована.
        +13
        На сегодняшний день производительность Python кода уступает Java, Ruby.

        Я всегда считал что Python не уступает в производительности Ruby, мало того, был уверен что превосходит…
          +1
          Некоторое время назад я тестировал производительность PyPy с JIT, на моих скромных задачах он уступал коду на Си всего в три раза (в то время как CPython работал в десятки раз медленнее). За одно я попробовал что-то вроде Shed Skin, и получил такую же производительность, как в Си.
            0
            Я почему-то думал, что Ruby — JIT компилируемый. Видимо перепутал с Rubinius.
              +2
              Кстати, мне очень понравился Cython. В Shed Skin насколько я знаю слишком много ограничений. В Cython например, что бы отключить GIL можно сделать так cdef void my_gil_free_func(int spam) nogil. И конечно, скорость очень близка к Си.
              +3
              В среднем Python чуть быстрее. В Ruby 2.0 видимо заморочились (судя по CPU load) и сделали много оптимизаций для типичных задач.
                0
                А вот куда интереснее, что в PHP 5.5 наделали столько оптимизаций, что он уже обгоняет (в среднем) большинство старых добрых врагов.
                  +19
                  Медлительность — не главный недостаток PHP.
                0
                Ruby уступает, по-крайней мере в бенчмарках.

                Более того для Python есть добро вроде Nuitka, который пожизненно ускоряет код (хоть и с оговорками).
                  +2
                  Nuitka по скорости не обгоняет Cython
                    +1
                    А еще есть www.stackless.com/
                  –12
                  Печально что люди которые создают системообразующие вещи «не менеджеры и даже не team lead». Это к слову о карьерном росте в сфере ИТ, а точнее его полном отсутствии.
                    +17
                    С чего бы? Если человек не хочет быть менеджером, его все равно нужно заставлять?
                      +5
                      Он же работает на полставки, а то и меньше.
                        +7
                        Печально как раз то, что молодые инженеры, поработав пару-тройку лет и только-только научившить хоть что-то делать правильно, уходят в менеджмент, а им на смену приходят новички. В итоге в менеджменте те, кто не умеет управлять, а задачи решают те, кто не умеет их решать.
                        Ну и быть рядовым инженером в хорошей компании, для меня лично гораздо веселее, чем «быть менеджером или даже team-lead».
                          0
                          Очень согласен!

                          Скорее всего такое представление (управленец — человек первого сорта, инженер — второго) складывается из-за того, что большинство людей не видят развитие себя в техническом плане. И получается, что вместо хорошего системного архитектора появляется плохой тим лид.
                        0
                        Кстати о лямбда-выражениях, может кто помнит ссылку где было обсуждение нового синтаксиса?
                        • UFO just landed and posted this here
                            +15
                            Это поразительно.
                              +1
                              Кто же поверит без второго фото? provocation.jpg
                              • UFO just landed and posted this here
                                +5
                                Здесь будет трагический рассказ о том, как ваш отец, таинственный программист из Голландии, бросил вас в младенчестве, оставив на память о себе только одну старую потертую фотографию?
                                • UFO just landed and posted this here
                                    +5
                                    настоящий годный sarcasm может быть только в png!
                                –1
                                По иронии судьбы его первый проект в Google (Mondrian, code review system) был переписан на Java. Причины — больльшой проект на Python практически невозможно поддерживать. Теперь вот Java/GWT.
                                  +5
                                  Почему невозможно? А как же youtube, disqus, dropbox? Django, wingware тоже не маленькие проекты и ничего, поддерживают :)
                                    +4
                                    Думаю, причины скорее в том, что проект на Java будет работать куда быстрее. В масштабах Google выигрыш даже 10% производительности выливается в огромную экономию.
                                      0
                                      >Причины — больльшой проект на Python практически невозможно поддерживать

                                      Почему? Из чего это следует? Поддерживаемость в первую очередь зависит от культуры разработки в компании, и, только после кучи других факторов, самого языка.
                                        0
                                        был переписан на Java

                                        Это про Gerrit? Судя по всему это клон Mondrian для Git, т.к. сам Mondrian поддерживает Perforce.
                                        И Google все еще использует Perforce.
                                          0
                                          > Это про Gerrit?
                                          Нет. Если быть уж совсем точным — вначале был Mondrian, потом Shawn Pearce начал Gerrit (на java) с интерфейсом похожим на геррит. Потом Google разработчики склонировали интерфейс Gerrit и написали внутреннюю систему, которая заменила Mondrian.

                                          > И Google все еще использует Perforce.
                                          Not anymore.
                                            0
                                            >> И Google все еще использует Perforce.
                                            > Not anymore.
                                            Неужели абсолютно все проекты перешли на Git?
                                        –10
                                        Одна маленькая деталь — в голландском «v» читается как «ф» (точно как в немецком — ну, вы знаете, «Volkswagen» == «Фольксваген»).
                                        Поэтому он все же «фан Россум» а не «ван Россум».
                                        Хотя это, конечно, мелочь.
                                          +7
                                          Другая маленькая деталь: вы — не правы, если считаете голландский немецким.
                                          Для начала, если хотите, можете ознакомиться с правилами нидерландско-русского транскрибирования.
                                            0
                                            Я не считаю голландский немецким, но касательно произношения приставки «van» никаких сомнений нет.
                                              0
                                              Вы правы, "v" в голландском соответствует звуку англ. "f", но практическое транскрибирование из голландского в русский предполагает переход этого звука в русское "в". Так сложилось исторически, так что тут все правильно. Вспомните известных футболистов: Марко ван Бастена, или Руда ван Нистелроя.

                                              Вот в немецком «von» действительно переходит в «фон»: Отто фон Бисмарк.
                                                +1
                                                Ван Гог!
                                          +2
                                          А то Я бы спросил: «Когда появится JIT компиляция в Python?» На сегодняшний день производительность Python кода уступает Java, Ruby.

                                          Мне кажется он отвечал на подобный вопрос на «кейноте», ответ был примерно таким: «У Python с производительностью все в порядке, если вас не устраивает скорость, то возможно вы выбрали не подходящий инструмент для конкретной задачи.»
                                            0
                                            Обе компании уже думают о Python 3.

                                            Only users with full accounts can post comments. Log in, please.