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)
Ответ на: комментарий от Leron

В луа тоже есть киллер-фича. Можно добавить несколько строчек в начале кода, и поведение необъявленных переменных будет как в питоне.

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

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

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

Можешь считать это чем захочешь. Каминг-аутом, банкой варенья, овощерезкой - чем угодно.

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

Если использовать постоянно with при открытии файлов понятно когда он закроется, с try(или без) мне придется поискать

Если все идет, как надо, то до ближайшего finally().

Странно видеть у Python больше инкапсуляции чем в java.

class MyResource implements AutoCloseable

это уже не ниша python

Это называется «провокация говнокода». Хотя, язык позволяет указывать вероятные эксепшены. Для тяп-ляп случаев и сам себе разраб - ok.

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

Асинхрон
в скпиптоте
гуи

Ты скриптоту с чем-то другим путаешь.

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

Даже на самый говённый язык есть спека

Нет. Часто есть только референсная реализация и всё, крутись как хочешь. Кстати, давно у питона появилась спека?

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

А в рамках ES5 это и вовсе самый простой скриптовый язык, но там есть всё, чтобы грабить корованы.

Например, модульность и вменяемое, а не perl5-style, ООП.

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

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

Да вы оба раскрылись.

Для одного частичная проверка равна отсутствию проверки. Для другого частичная проверка равна наличие проверки.

И то и другое формы извращения.

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

А что, в питоне вменяемое ООП? Не заметил. Модульность костылится на замыканиях как и всё прочее. Нет лишь сахарка для классов и модулей, но это несущественно. А теперь и сахарок есть.

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

Ну, кому и кобыла невеста.

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

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

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

Т.е. твой use case - использовать как псевдокод (чел не знает python, главное - показать концепцию и т.д.). А у меня - ынтерпрайз и проект, который переживает не одного сопровождающего. Отсюда и разные требования к инструменту. Мне, чем меньше нюансов, неоднозначностей и проще спека - тем лучше. И хрен с затратами на написание лишнего кода, главное, чтоб проще сопровождать и надежнее.

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

Для одного частичная проверка равна отсутствию проверки.

не то чтобы я на 100% согласился, но думаю, что это комплимент.

И то и другое формы извращения.

такая наша работа.

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

А что, в питоне вменяемое ООП? Не заметил. Модульность костылится на замыканиях как и всё прочее.

bread ★ (13.07.2018 15:52:32) [«пиши всякую ересь, кто там будет проверять. Я всегда так делаю»]

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

не то чтобы я на 100% согласился, но думаю, что это комплимент.

Вот только про тебя была вторая часть. Так что «комплимент» не тебе.

anonymous
()

Гвидо перешёл на Go?

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

Дак-тайпинь — это не баг, это фича

Это таки баг. Ссылки на исследрование под рукой нет, но 90% Python-кода статически типизировано по факту.

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

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

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

Для другого частичная проверка равна наличие проверки

может ты и прав. постараюсь исправиться

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

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

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

В вашем стандартном тернарном операторе используются ? и :. В JS эти символы где-нибудь используются ещё в синтаксисе? То есть хрень, которую видишь раз в год. В питоне там обычный if, обычный else. Даже если забыл, что на какой позиции должно быть, условие и инварианты, это буквально интуитивно читается, по-английски.

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

Если использовать постоянно with

Кстати, в java тоже есть похожая фича, try-with-resources. Хотя особо не прижилась, несмотря на то, что реализовали для чего только можно.

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

Я тоже всегда читаю диффы перед коммитом

+= 1

а потом пачки коммитов перед тем как сливать ветки

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

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

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

Смысл в том, что используя язык все равно читать спеку. Тогда смысл конструкций with или try ясны. Дред выше предлагает понимать код без спеки. А я против :).

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

А что, в питоне вменяемое ООП? Не заметил. Модульность костылится на замыканиях как и всё прочее.

bread ★ (13.07.2018 15:52:32) [«пиши всякую ересь, кто там будет проверять. Я всегда так делаю»]

Кто же виноват, что ты не шаришь в жаваскрипт

Не шарю. Но ты-то писал ересь (как обычно) о Python.

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

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

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

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

Не всё так однозначно. Конечно, аннотации помогают понимать код. Но на самом деле они уже содержаться в коде (вывод типов), и писать их отдельно незачем. Можно сделать :t func в соседней сессии GHCi, и увидеть то же самое. Потом кто-то захочет больше интерактива — ничего не мешает показывать тип функции «при наведении мышкой», если настроено IDE. Если хочется показать тип сразу всех топ-левел функций — это опять же можно сделать на уровне IDE, а не на уровне исходного кода. Вот примерно так. А те, у кого нет IDE, должны страдать, да :)

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

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

Конечно, аннотации помогают понимать код. Но на самом деле они уже содержаться в коде (вывод типов), и писать их отдельно незачем.

Есть зачем. Если так не делать, при whole program type inference ошибки могут вылезать в самых неожиданных местах.

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

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

Нет, спека — это способ формализации.

Формализация, среди прочего, проясняет неочевидные вещи.

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

Тема не раскрыта

что конкретно тебе раскрыть? пример показать?

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

Песец, ты и в контекст не можешь.

Ты видишь, как в Python модульность и ООП костылятся на замыканиях. «Мели, Емеля, твоя неделя» (ц)

Таки питон сглаживает извилины.

Ага, вали с больной на здоровую.

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

А что, в питоне вменяемое ООП? Не заметил.

В пределах обозначенной модели с утиной типизацией? Вполне вменяемое.

Модульность костылится на замыканиях как и всё прочее.

Костылится — отличное слово. Про инструментэйшн из коробки, конечно, приходится только мечтать, кто как хочет, тот так и... развлекается.

Я недаром упомянул perl5 в качестве образца. Там тоже можно было «все». Потроха, правда, наружу торчали, о стандартизации MRO до поры никто не задумывался, «нуачовсежработает!». Да, я в курсе, что добрые люди потом в рамках CPAN и иерархию исключений сделали вменяемую, и интроспекцию стандартизовали, и многое еще прикрутили, так что, где-то с 2007-го, наверное, года ООП в перле стал похож на ООП, а не на свалку запчастей для ООП.

Ну, то есть, то, что в питоне 1.5 уже было само собой разумеющимся.

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

Мало того cахарку, мало. Да и не держит его никто, иначе не составляли бы люди таблички вроде https://node.green/

Так что, без бабеля не обойтись...

И это, замечу, во времена, когда C++17, Java9 и прочие груви практически в каждый дом пришли :)

AlexM ★★★★★
()
Ответ на: комментарий от Crocodoom
class SomeDataStructure:
    @json_table
    def server(interface: [expandable], port):
        pass

expandable, допустим, означает, что содержимое поля interface подлежит препроцессингу

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

Современные веяния вообще не предполагают чтение спеки, такова реальность. В том же Go, ты быстренько пробежал туториал с примерами и вперёд говнокодить. А по рукам тебя уже будут бить компилятор и автоматические инструменты, и это вполне рабочий вариант.

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

Модульность это про жаваскрипт, дурачок.

Дурачок набрал пост вот с такими словами: «А что, в питоне вменяемое ООП? Не заметил. Модульность костылится на замыканиях как и всё прочее.» И, что характерно, подпись под словами этого дурачка стоит твоя.

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

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

Не-а. Этот персонаж сознательно «пишет ересь».

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

90% Python-кода статически типизировано по факту.

Ну, потому что не подумали о нормальных трейтах заранее.

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

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

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

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

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

Они предполагают основные конструкции и концепции языка. И концепция исключений проще концепции менеджера контекста не говоря уже о всяких декораторах, yeld и т.д.

и это вполне рабочий вариант.

для сайтика васяна - это пройдет. А для склада - уже не.

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

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

Ну, если ты веришь в это - дело твое.

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

90% Python-кода статически типизировано по факту.

Ну, потому что не подумали о нормальных трейтах заранее.

Да нет, просто динамическая типизация почти никогда не нужна.

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

У меня контора небольшая, мне не сложно, в моих проектах помимо меня отсилы ещё пара разработчиков ковыряется. Их коммиты я тоже читаю. Но когда сам лезу в чужие проекты, то это боль.

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

Кому надо те поняли. На питонистов и не рассчитано (разве что случайно у кого то полыхнет, но конечно же нашелся и такой).

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