LINUX.ORG.RU

Гвидо ван Россум покидает пост BDFL языка Python

 


3

7

Создатель и один из основных разработчиков языка программирования Python Гвидо ван Россум объявил о том, что устраняется от принятия дальнейших решений о развитии языка. В течение какого-то времени он продолжит выполнять функции рядового разработчика и консультировать команду, но фактически Гвидо складывает с себя полномочия «великодушного пожизненного диктатора» (benevolent dictator for life, BDFL), которыми он обладал 27 лет с момента создания языка. Сейчас в списке рассылки python-committers идет дискуссия о новой модели управления разработкой Python.

Гвидо принял решение после утверждения PEP 572 «Assignment Expressions» (Предложение об улучшении языка №572 — «Выражения присваивания»), вокруг которого в сообществе разработчиков и пользователей языка развернулись ожесточенные дискуссии. «Я больше не хочу когда-либо сражаться за PEP и видеть, как множество людей презирают мои решения» — сказал ван Россум.

PEP 572 добавляет в язык выражение присваивания вида var := some_expression и будет реализовано в Python 3.8 (сейчас присваивание является оператором, не вырабатывающим значения).

Сегодня днем на рассылку разработчиков языка Python пришло письмо следующего содержания:

Теперь, после того, как PEP 572 утверждено, я больше не хочу когда-либо сражаться за PEP и видеть, как множество людей презирают мои решения.

Я хотел бы полностью устраниться от процесса принятия решений. Я все еще буду какое-то время участвовать в разработке в роли рядового разработчика, и я буду доступен для консультаций, возможно, больше, чем прежде. Но я, по сути, ухожу в бессрочный отпуск с позиции BDFL, и вам придется существовать самостоятельно.

Так или иначе, рано или поздно это все равно должно было случиться — автобус всё еще подстерегает за углом, и все мы не молодеем... (Не буду вдаваться в подробности о состоянии своего здоровья.)

Я не планирую назначать своего преемника.

Так что вам придется самим решать, как быть дальше. Установить демократию? Анархию? Диктатуру? Федерацию?

Я не думаю, что мой уход серьезно затронет повседневные решения по задачам в трекере и на GitHub. Моим мнением там интересуются очень редко, и на самом деле, как правило, оно не так важно. Так что в этом плане дела будут идти своим чередом.

Наиболее существенные решения, которые мне приходилось принимать, это, пожалуй:

  • Какая судьба ожидает новые PEP
  • Принятие новых разработчиков языка в команду

Мы можем оформить эти процедуры в виде PEP (возможно, эти PEP составят своего рода конституцию языка). Но суть такова: я хочу попробовать дать вам (текущим разработчикам) самим решить все это для себя.

Обратите внимание, что вы все еще обязаны подчиняться Правилам поведения сообщества — если вы не согласны с этим документом, пожалуй, единственный выход для вас — добровольно покинуть эту рассылку. Возможно, нам еще стоит обсудить, не стоит ли кого-то исключить отсюда (тогда придется заодно исключить их и из рассылок python-dev и python-ideas, так как они тоже подчиняются Правилам).

И последнее — напоминаю, что архивы этой рассылки публичны (https://mail.python.org/pipermail/python-committers/), несмотря на то, что участие в ней ограничено (только для разработчиков языка).

Я все еще буду с вами, но я хочу дать вам возможность самим решать за себя. Я устал, и мне нужен долгий перерыв.

-- Гвидо ван Россум (python.org/~guido)

>>> Подробности



Проверено: tailgunner ()
Последнее исправление: tailgunner (всего исправлений: 13)
Ответ на: комментарий от cab

с python, незнакомым с кодом в целом придется ввобдить концепции циклов и условий и переменных и кучу всего

А для этого есть спека языка

как это противоречит тому что оно не очевидно ? Для питона тоже есть спека и исходники, как и для других языков

Dred ★★★★★
()
Ответ на: комментарий от MyTrooName

Если контракт не проверяется автоматически, он не проверяеьтся вообще

это только у говнокодеров без надзора

Это в реальной жизни, а не у идеальных кодеров под анальным надзором.

Просто ради ясности: для тебя непроверяемые контракты - это способ писать код, в котором ты уверен?

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от cab

Я из клана тех, кто велосипедил проверку типов как только появились декораторы

А я не стал - понял, что навелосипедить можно только проверку в рантайме, а нормально сделать - сил не хватит.

tailgunner ★★★★★
()
Ответ на: комментарий от Dred

Матц написал, что Гвидо теперь может смотреть ютуберш которые на камеру съедают кучу еды и Гвидо сразу запостил канал с одной подобной девчонкой японской.

Exmor_RS ★★★
()
Ответ на: комментарий от tailgunner

непроверяемые контракты

не проверяемые автоматически контракты

это способ писать код, в котором ты уверен?

это необходимый способ писать код, в котором я уверен

MyTrooName ★★★★★
()
Последнее исправление: MyTrooName (всего исправлений: 4)
Ответ на: комментарий от MyTrooName

это способ писать код, в котором ты уверен?

это необходимый способ писать код, в котором я уверен?

Ты спрашиваешь меня, но я не знаю. Если непроверяемые контракты - это «необходимый способ писать код, в котором я уверен», скажи об этом прямо.

tailgunner ★★★★★
()
Ответ на: комментарий от RazrFalcon

Асинхрон в скпиптоте нужен, чтоб гуи не фризился, чтоб скрапить и т.п. Но любой, даже юзертредов хватит.

Shadow ★★★★★
()
Ответ на: комментарий от MyTrooName

Я перечитал. Там нет ответа, только вопрос. Я думаю, ты избегаешь прямого ответа, потому что понимаешь, как нелепо он звучит.

tailgunner ★★★★★
()
Ответ на: комментарий от Dred

с python, незнакомым с кодом в целом придется ввобдить концепции циклов и условий и переменных и кучу всего

А зачем пускать к python-коду незнакомого с python человека? Пусть сначала получит необходимый минимум. Так, что,наверное, все же, наоборот. Незнакомому с python «придется ввобдить концепции циклов и условий и переменных и кучу всего». А вот незнакомый с конкретным кодом может что-то и учудить.

как это противоречит тому что оно не очевидно ?

Спека призвана прояснить неочевидные вещи, не?

Человек, знакомый с языком сразу видит, что оба оператора защищают код. Просто в случае с try возможные проблемы сразу видно, а в случае с with надо быть внимательнее.

cab ★★★★
()
Ответ на: комментарий от tailgunner

с учетом того, что я удалил вопросительный знак почти мгновенно, ты либо моментально отреагировал на мой пост, и сочинял свой ответ из двух предложений 5 минут, либо... остановимся на первом варианте

MyTrooName ★★★★★
()
Ответ на: комментарий от MyTrooName

То есть непроверяемые контракты - это необходимый способ писать код, в котором ты уверен. Окей, больше вопросов нет.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

А я не стал - понял, что навелосипедить можно только проверку в рантайме, а нормально сделать - сил не хватит.

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

cab ★★★★
()
Ответ на: комментарий от tailgunner

То есть непроверяемые контракты - это необходимый способ писать код, в котром ты уверен

не проверяемые автоматически. ты можешь считать, что других не бывает, но не надо приписывать мне свои слова.

MyTrooName ★★★★★
()
Ответ на: комментарий от cab

во вторую ветку анотаций типов, еще не завезли.

Во вторую ветку (как минимум в 2.7) аннотации типов завезли вместе с mypy. Правда, аннотации приходится писать в комментариях, но это гораздо лучше, чем ничего.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Во вторую ветку (как минимум в 2.7) аннотации типов завезли вместе с mypy

Когда ввели декораторы: в 2.3 или 2.4? До 2.7 еще долго ждать, а сейчас я на python не пишу уже года 2 или 3.

cab ★★★★
()
Последнее исправление: cab (всего исправлений: 1)
Ответ на: комментарий от MyTrooName

документация - нужна. типы в документации - нужны. засорять объявление метода второстепенной для duck-typing языка информацией - не нужно. имён параметров вполне достаточно.

Да аннотации типов это та же документация, просто не в докстрингах, а как часть синтаксиса. Это более естественно. А что их ещё можно проверить сторонним инструментом — не принципиально, хотя приятный бонус. Наверное типы в докстрингах тоже можно как-нибудь проверять. Но первичен тут именно вынос документации типов в синтаксис.

Crocodoom ★★★★★
()
Ответ на: комментарий от Shadow

чтоб гуи не фризился

Писать гуи на скриптоте - ССЗБ.

RazrFalcon ★★★★★
()
Ответ на: комментарий от cab

случае с with надо быть внимательнее.

я в упор не понимаю где надо быть внимательнее. Ты про отступы ? Ну у меня за все время знакомства с Python не было проблем с отступами, а вот продолбаные скобки были. И With ты видешь в начале блока, сразу понятен контекст. Да finally из Python никто не убирал, только не все любят еще в try оборачивать код когда не требуется избежать экстренного завершения в случае ошибки.

Спека призвана прояснить неочевидные вещи, не?

только для этого ее надо держать в голове и каждый раз вспоминать как оно должно работать

А зачем пускать к python-коду незнакомого с python человека?

Проектирование ? Мат. модели ? Описания алгоритмов ? Это весьма действенные практики при анализе данных. Куда проще показать действующий код обработки, чем строить для него концепции. (И да, пмне приходится иногда показыать код на разных языках, в тмо числе на java и cи, python пока что наиболее понятный)

Dred ★★★★★
()
Ответ на: комментарий от Crocodoom

Да аннотации типов это та же документация, просто не в докстрингах, а как часть синтаксиса. Это более естественно

на самом деле это дело вкуса. в статических языках аннотации типов нужны однозначно. в питоне? спорно. я предпочту зарезервировать аннотации для других целей

Наверное типы в докстрингах тоже можно как-нибудь проверять

можно

MyTrooName ★★★★★
()
Последнее исправление: MyTrooName (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Если контракт не проверяется автоматически, он не проверяется вообще

Я точно знаю, что другие бывают.

хорошо, что ты изменил своё мнение.

MyTrooName ★★★★★
()
Ответ на: комментарий от tailgunner

для ясности: ты все еще считаешь, что если контракт не проверяется автоматически, то он не проверяется вообще?

MyTrooName ★★★★★
()
Ответ на: комментарий от MyTrooName

все еще считаешь, что если контракт не проверяется автоматически, то он не проверяется вообще?

Да, конечно. Но существуют и другие контракт - те, которые проверяются автоматически.

tailgunner ★★★★★
()
Ответ на: комментарий от Dred

я в упор не понимаю где надо быть внимательнее

если у тебя твой менеджер контекста и что-то пошло не так. В случае с try ты всегда видишь возможные проблемы. В случае with, когда проблемы наступают, тебе лезть в код твоего менеджера контекста.
И персонально для меня, плохо читаемый with.

только для этого ее надо держать в голове и каждый раз вспоминать как оно должно работать

Так, тебе надо держать 100500 нюансов и концепций python-а в голове (основная причина, почему я с python-а слез). Лично для меня, лучше держать нюансы самого try, без with.

cab ★★★★
()
Последнее исправление: cab (всего исправлений: 1)
Ответ на: комментарий от tailgunner

существует два вида контрактов, первые проверяются автоматически, вторые не проверяются вообще. третьего, по-твоему, не дано, правильно?

MyTrooName ★★★★★
()
Ответ на: комментарий от MyTrooName

на самом деле это дело вкуса. в статических языках аннотации типов нужны однозначно. в питоне? спорно.

Ну вот кстати в языках с мощным выводом типов эти аннотации зачастую та же документация. Потому что и без неё всё работает, но с аннотациями как-то понятнее. Яркий пример - Хаскель, там принято все топ-левел функции аннотировать, хотя это совсем и не обязательно, и есть противники такого подхода. И аннотации в Питоне я воспринимаю так же.

я предпочту зарезервировать аннотации для других целей

Для каких, например?

Crocodoom ★★★★★
()
Ответ на: комментарий от tailgunner

стандартный пример на контракты:

buffer = []
# контракт: перед каждой проверкой условия цикла,
# буфер + содержимое файла после текущей позиции
# равно полному содержимому файла
while line := f.readline():
    buffer.append(line)

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

MyTrooName ★★★★★
()
Ответ на: комментарий от cab

Так, тебе надо держать 100500 нюансов и концепций python-а

Поэтому я пригорел от:=, теперь да, теперь нужно. Если использовать постоянно with при открытии файлов понятно когда он закроется, с try(или без) мне придется поискать, а в случае с java еще и обыскать finally на наличие return. Как бонус, это позволяет повесить обработку закрытия дескриптора на сам объект, а не на пользователя. Странно видеть у Python больше инкапсуляции чем в java.

В случае с try ты всегда видишь возможные проблемы

глупости, в try можно что угодно обернуть, хоть весь код, все что я увижу, то что вероятно я не пропущу ошибку потому что её кто-то заглушил. В java оно действительно понятнее тем что приходится указывать вероятные эксепшены, но это особенности статической типизации, это уже не ниша python (и даже тут try не обязателен)

Кстати, как ни странно, один из самых понятных способов обработки ошибок - в Go, хоть раньше он мне и не нравился (например потому что его по-сути и нет), но бывает крайне удобно, просто возвращать ошибку как часть результата работы функции, это например позволяет проще организовать обработку и слить это в одну точку.

Dred ★★★★★
()
Последнее исправление: Dred (всего исправлений: 1)
Ответ на: комментарий от MyTrooName

существует два вида контрактов, первые проверяются автоматически, вторые не проверяются вообще. третьего, по-твоему, не дано, правильно?

Именно так.

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

Работоспособность кода проверяется тестами, естественно. Соблюдение контракта в приведенном тобой случае не проверяется никак.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от Dred

Куда проще показать действующий код обработки, чем строить для него концепции.

мне уже страшно. По факту, python навороченный язык с кучей нюансов. Каков шанс, что незнакомый с ним человек сделает неправильные выводы несмотря на типа читабельность?

cab ★★★★
()
Ответ на: комментарий от Crocodoom

Яркий пример - Хаскель, там принято все топ-левел функции аннотировать

мне кажется, потому и принято, что это необходимо (не для компилятора, а для человека). крайняя (не в смысле последняя) точка опоры для понимания кода функции. чтобы не только изнутри можно было начинать, но и снаружи.

есть противники такого подхода

я их не понимаю. плохого-то что?

Для каких, например?

метапрограммирование, DSL, вся фигня

MyTrooName ★★★★★
()
Ответ на: комментарий от MyTrooName

f.readline()

А теперь представь рефакторинг и этот самый readline меняет свое поведение. Так как становится объектом другого типа.

Так конечно же проверишь весь код глазами.

anonymous
()
Ответ на: комментарий от tailgunner

Соблюдение контракта в приведенном тобой случае не проверяется никак.

ты не поверишь. строгое доказательство в три предложения

MyTrooName ★★★★★
()
Ответ на: комментарий от Virtuos86

Присвоить переменной значение X, если выполняется условие Y, иначе присвоить значение Z

Какой-то самообман. У тебя лишь одно присваивание по факт, и идет оно не в самом начале, а после объявления переменной. С тем же успехом и ты и стандартный тернарный оператор можешь не менее естественно прочитать «Если выполняется условие Y, то присвоить переменной значение X, иначе Z».

anonymous
()
Ответ на: комментарий от MyTrooName

И так будет работать :

for line in f:
    buffer.append(line)

mx__ ★★★★★
()
Ответ на: комментарий от anonymous

А теперь представь рефакторинг и этот самый readline меняет свое поведение. Так как становится объектом другого типа.

конечно, если изменить контракт на используемые функции тем или иным образом, проверять придется заново. неавтоматически. или вылавливать баги постфактум.

Так конечно же проверишь весь код глазами.

весь - не проверишь. но возможность есть.

я не оспариваю необходимость тех же юнит-тестов, наряду с документацией в частности и контрактами вообще. но я просто не представляю, как это - писать код from scratch, без контрактов. я либо держу контракт в голове, либо использую двести раз проверенный сниппет, как мой пример. в противном случае остается только молиться, что код будет работать. не зная контракт, ты его даже тестами правильно не покроешь.

собственно юнит-тесты и нужны только на случай рефакторинга или любых других изменений. в противном случае можно было бы один раз протестировать код ручками.

MyTrooName ★★★★★
()
Ответ на: комментарий от tailgunner

Ты передёргиваешь, по сути лжешь и разводишь демагогию.

Все протоколы и стандарты — точно такие же контракты, но почему-то всё у всех работает.

При этом речь не о «существует» / «не существует», а о концепции, доки точно так же можно проверять, тем более, что существующие инструменты для проверки по аннотациям всё равно в зачаточном состоянии. Если бы вместо проталкивания вредного пепа написали инструменты для проверки типов из докстрингов или каких-то внешних источников, они бы были.

Твоя аргументация звучит по сути так «аннотации это нужно и хорошо, потому что они есть».

WitcherGeralt ★★
()
Последнее исправление: WitcherGeralt (всего исправлений: 1)
Ответ на: комментарий от tailgunner

А докстринги ты можешь проверить только ручками и это означает, что проверять их ты не будешь

это означает, что ты - беспризорный говнокодер

MyTrooName ★★★★★
()
Ответ на: комментарий от WitcherGeralt

Он, очевидно, имеет ввиду статический анализ методом пристального взгляда.

именно так я и поступаю в 90% случаев. в других 10% - сниппет

MyTrooName ★★★★★
()
Ответ на: комментарий от MyTrooName

А докстринги ты можешь проверить только ручками и это означает, что проверять их ты не будешь

это означает, что ты - беспризорный говнокодер

Это означает, что я не вру ни себе, ни другим. А ты - врешь.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

это означает, что ты - беспризорный говнокодер

Это означает, что я не вру ни себе, ни другим

можно считать это каминг-аутом?

MyTrooName ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.