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)

Ответ на: комментарий от RazrFalcon

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

Мир не крутится вокруг тебя, а применение питона не ограничивается скриптами.

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

Не заменяется, контекстный менеджер — это гораздо больше чем прото try-finally. Заменив один контекстный менеджер на другой

Чаще всего ты просто пользуешься уже готовыми менеджерами и не так часто пишешь свой. А try/filally удобен тем, что ты сразу видишь, что тебе ждать от метода, а не лезешь смотреть в подмену.

Просто надо либо трусы надеть, либо крестик снять: либо мы сосредотачиваемся на удобстве кодирования, либо чтения. Кодировать со всем вышеперечисленным удобней, я не спорю. Читать уже нет.©cab

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

Если к отсутствию стандартной либы (тут у у IE11 console.log не (всегда) обнаруживается) добавить бардак с синтаксисом и фактически отсутствующие стандарты оформления модулей (хуже, чем в perl5 в свое время), а также затянувшийся переезд на стандарты оформления асинхронности — ну, я даже не знаю, действительно ли это «лучше».

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

Но Гвидо не хочет ничего слышать, и прогнулся максимум под узаконенные type hints, которые для интерпретатора остаются просто синтаксическим мусором.

Ну Гвидо прав, аннотации типов в динамическом языке это шизофрения. Хинты для внешних чекеров разумный компромис. Хотя может возникнуть забавная ситуация, когда хинты разошлись с кодом и вводят всех в заблуждение, как с доками случается. Так то конечно странно брать скриптоту и мудохаться с типами, извращения для тонких ценителей.

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

Если у f нет **kwargs, то это присваивание значения переменной a.

Так и в случае a:=1 это тоже присваивание. Нет?

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

Так и в случае a:=1 это тоже присваивание. Нет?

Ты обещал вывести вид присваивания из контекста. Я дал контекст: f(a=1). Выведи вид операции присваивания.

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

Читать with тоже проще (мне, не-питонисту): ты просто знаешь что ресурс освободится после использования. try/finally/способ-освобождения - низкоуровневые детали.

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

А зачем в документации типы?

Чтоб знать с чем работает функция.

Но ведь функция может работать с аргументами совершенно другого типа. В докстринге можно написать что угодно - это никто не проверяет.

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

Как это описывает моя жена

круто. она не замужем?

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

А как хорошо начал-то

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

Я, наоборот, путаюсь постоянно в JS с «правильным» тернарным оператором. Питоновский читается естественнее, как по мне. «Присвоить переменной значение X, если выполняется условие Y, иначе присвоить значение Z.»

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

Сначала значение, потом условие, потом ещё одно значение — ну офигеть как естественно.

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

Но ведь функция может работать с аргументами совершенно другого типа. В докстринге можно написать что угодно - это никто не проверяет.

Я не раз стречал в доке, что передавай строку и т.д. Т.е. функция расчитана на строку. Сегодня оно работает и со списком, а завтра выдаст исключение. На что мне полагаться в отсутствие статики или вывода типов? На докер?

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

Списковые вкючения кстати тоже отличная штука, сразу же понятно что внутри цикл и что он генерирует, куда удобнее map и filter, которые как раз надо было отправить туда же куда и reduce

в целом, согласен, но map(str, array) стопудово лучше, чем (str(x) for x in array)

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

В аннотациях тоже можно написать что угодно и не проверять.

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

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

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

Шта?

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

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

Ок. Перефразирую. foo(a=1) ведет к себя как foo(a:=1). На первый взгляд это не ломает совместимость.
Я могу ошибаться, на python давно не писал.

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

Ну Гвидо прав, аннотации типов в динамическом языке это шизофрения

Нет, Гвидо был не прав. Хинты в динамическом языке это удобный способ делать type assert без лишней писанины.

no-such-file ★★★★★
()
Ответ на: комментарий от cab

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

меня на этот счет разубедила книжка шихановича, где он 9 разных смыслов символа «=» чисто для примера приводит, и всё из школьной программы.

одним больше, одним меньше...

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

foo(a=1) ведет к себя как foo(a:=1)

Тогда функция f не получит параметр a. Программа сломается. «Вывод из котекста» провалился.

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

Утверждается, что type assert'ы — порочны по своей сути. Особенно, в динамическом языке

В лучшем случае, трейты.

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

Как на мой вкус - нет. Особенно учитывая отступы.

Ну не знаю, мне вот не очевидно что finally работает раньне return в try (хотя и понимаю зачем) и в результате, если в finally тоже будет return (по какой-то причине это допустимо), то результат из метода вернут именно он.

Я согласен, что подход с try-finally упрощает работу с несколькими дискрипторами, но вот with лучше визуально обозначает область внутри которой будет доступен объект.

Читать уже нет.

на то он и не Basic, но все же на Python куда проще написать код который сможет прочесть незнакомый с ним человек, на Cи или Java (или Ruby, если сравнивать похожие) это сделать в разы сложнее, а местами - невозможно.

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

Шта?

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

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

«Вывод из котекста» провалился.

ok

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

путаюсь

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

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

Последний js не плох, да. Я про луа написал.

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

А try/filally удобен тем, что ты сразу видишь, что тебе ждать от метода, а не лезешь смотреть в подмену.

try:
    ...
finally:
    f.close()

поди угадай, что делает f.close()

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

Мир не крутится вокруг тебя

Мир крутится вокруг питона. JS совсем недавно залез в эту нишу.

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

Это не проблема из жизни, а бессмысленный кусок текста.

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

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

А зачем в документации типы?

затем же, зачем и всё остальное. контракт.

Зачем нужен контракт, который не проверяется?

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

ну, я даже не знаю, действительно ли это «лучше»

JS значительно проще, даже с нашлепками ES6. А в рамках ES5 это и вовсе самый простой скриптовый язык, но там есть всё, чтобы грабить корованы. Да, и на жс есть стандарты в отличие от. И обратная совместимость.

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

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

Прекрасно. Напомни, ты из клана тех, кто считает аннотации типов бесполезными?

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

Зачем нужен контракт, который не проверяется?

ты ставишь под сомнение нужность документации вообще?

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

Так я могу услышать ответ на свой вопрос? Напомню его: «Зачем нужен контракт, который не проверяется?».

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

мне вот не очевидно что finally работает раньне return в try

А для этого есть спека языка. И лично я добавляю лог, чтобы видеть что и когда сломалось.

Python куда проще написать код который сможет прочесть незнакомый с ним человек

незнакомый с кодом или python?

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

Зачем нужен контракт, который не проверяется?

я предположу, что ты имел ввиду «Зачем нужен контракт, который автоматически не проверяется?»

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

https://ru.wikipedia.org/wiki/Контрактное_программирование

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

Напомни, ты из клана тех, кто считает аннотации типов бесполезными?

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

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

я предположу, что ты имел ввиду «Зачем нужен контракт, который автоматически не проверяется?»

Если контракт не проверяется автоматически, он не проверяется вообще. Но ты можешь отвечать и на вопрос «Зачем нужен контракт, который автоматически не проверяется?».

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

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

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

Но ты можешь отвечать и на вопрос «Зачем нужен контракт, который автоматически не проверяется?».

ответил выше

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

на выправленные питоном мозги

Сглаженные извилины это не очень круто.

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