Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

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

Anna | 16.06.2014 | нет комментариев
На прошлой неделе (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(), потому что эту функцию примерно неизменно применяли для 2-х пророческой: (а) Дабы подсчитать сумму элементов и (б) Дабы написать нечитаемый код. Следственно мы добавили встроенную функцию 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.

Источник: programmingmaster.ru
Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB