Не знаю что в PSF понимают под Visionary, но ничего хорошего такое визионерство языку не несёт. Конечно, если оно вообще что-то несёт. Но не вижу смысла продавливать отдельный термин для простого спонсорства — вряд ли PSF сама выбрала такую формулировку.
Цели, задачи, потребности корпорации планетарного масштаба принципиально отличаются от целей, задач и потребностей рядовых пользователей языка. Я даже не знаю как это оспорить можно. Я уже писал на тему целей Google при разработке Go в эссе о типизации в Python.
Своим текущим состоянием: идеологией, возможностями, распространённостью Python обязан в первую очередь рядовым пользователям, не Google.
В частности, одно из очевидных противоречий — вопрос гибкости и контролируемости кода.
Сделал ещё один заход на контроль типов в Python. На этот раз со стороны собственной библиотеки для контроля изменений типов переменных в runtime.
Общие выводы ясны из названия поста, хотя полученная библиотека более-менее работает и я попытаюсь её со временем довести до ума. Если разработчики Python наведут порядок у себя в проекте.
Как уже писал в обозрении актуального состояния типизации в Python, правильный подход к контролю типов в языке с динамической типизацией — делать контроль во время исполнения программы.
Краткое обоснование:
Из библиотек для контроля типов Python во время выполнения можно выделить только typeguard, которая позволяет контролировать входные и выходные параметры функций и методов. Это уже хорошо и удобно, но хочется большего.
Например, контролировать тип переменных и атрибутов при каждом присваивании им значения.
Библиотеку для такой функциональности я и попытался реализовать, но столкнулся с суровой реальностью.
Покопавшись в Julia решил зафиксировать мысли о текущем состоянии популярных языков программирования и их будущем. Без сильной аргументации и очень субъективно.
Раз в несколько лет я нахожу время, чтобы покопаться в наработках сообщества по «продвинутым» проверкам типов. Благо у меня под рукой есть взрослый, большой и нетривиальный проект, на котором можно безбоязненно ставить эксперименты.
Не могу сказать что я разделяю оптимизм по поводу продвинутой типизации в Python. Наоборот, считаю, что это как попытка пришить змее ноги — забавно, но вряд ли удобно. Но раз куча людей тратит на это время, надо быть в курсе.
В этот раз я:
Рассказывать буду тезисно, без глубоких обоснований, так как делать нормального качества обоснования для таких холиварных вопросов слишком долго, а я уже дней 5 на копание в этом потратил.
Большая часть поста не про mypy, а про философию проверки типов и будущее Python. Поэтому должно быть интересно, даже если сам mypy вас не интересует.
В этом уроке рассказывается, как запрограммировать подземелье. Если вы не программист, вам будет интересно почитать как придумать подземелье.
Несколько вечеров проверял идею генерации космических баз. Космическая база в итоге не получилась, а вот на добротное подземелье результат похож. Поскольку шёл от простого к сложному и никакой суровой магии не делал, то решил переработать код в урок по генерации подземелий на Python.
В итоге у нас получится генератор подземелий со следующими свойствами:
Весь код можно найти на github.
Кода в посте не будет — все используемые подходы легко описываются словами.
Для каждого этапа разработки в репозитории будет создан отдельный тэг, содержащий код на момент завершения этапа.
Задача этого урока не столько научить программировать генераторы подземелий, сколько показать, что кажущиеся сложными вещи на деле довольно просты, если их правильно разбить на подзадачи.