Недавно вышел mypy 0.940 с экспериментальной поддержкой паттерн-матчинга из Python 3.10. Тайп-чекер умеет выполнять проверку на полноту (exhaustiveness checking) для енумов и юнион-типов. Это полезно!

https://mypy-lang.blogspot.com/2022/03/mypy-0940-released.html

#mypy

В Python 3.11 стандартная библиотека пополнится модулем tomllib — как можно догадаться по названию, это про работу с TOML файлами. TOML уже стал популярным форматом для описания конфигурации, но до сих пор работа с ним в питоне возможна только через сторонние модули.

Отсутствие в стандартной библиотеке модуля для работы с этим форматом создаёт сложности для разного тулинга, который хочет читать оттуда свои настройки — форматтеры, линтеры, утилиты, связанные с управлением зависимостями и пакетированием. Особенно страдают именно утилиты из последней категории, например, pip или pipenv — они не могут позволить себе зависеть от сторонних пакетов. Им приходится просто вендорить стороннюю библиотеку к себе в код (Ctrl+C, Ctrl+V🗿).

Пока что tomllib будет уметь только читать формат. Интерфейс, по традиции, похож на json (load и loads). Запись решили не делать, потому что сложно, много нюансов, и мало кому нужно.

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

https://peps.python.org/pep-0680/

#pep #toml

А вы говорите у вас на проекте legacy. Тут в python закинули PEP по удалению неиспользуемых батареек и большинство датируется 90х годами.

https://peps.python.org/pep-0594/

#python

На самом деле PEP-594 уже давнишний, но его постоянно переносят на следующую версию. Наверное, чтобы подольше сохранить совместимость с Python 2 и не создавать лишних проблем обновляющимся. Вот, знайте, в 3.11 грядет большое количество новых депрекейшнов, а в 3.12 уже начнут удалять.

Meta (ага, та самая ныне экстремистская организация) продолжает донатить крупные суммы денег в Python Software Foundation. Напомню, что Python является для них довольно важной платформой — они даже поддерживают свой форк интерпретатора Cinder и пилят тайп-чекер pyre.

Благодаря этому пожертвованию, доказавшая свою успешность программа “Developer in residence” продляется еще как минимум на год. Łukasz Langa продолжает трудиться над нуждами проекта фулл-тайм до 2023.

https://pyfound.blogspot.com/2022/03/meta-deepens-its-investment-in-python.html

Кубок 🏆 в школьном соревновании по программированию черепашьей графики на Python. Выглядит круто!

https://www.reddit.com/r/Python/comments/ti7uyh/i_teach_python_for_middle_and_high_schoolers_i/

Уже 3.10.4 вышел. Каждую неделю релизы, ух!

Ничего особо не поменялось, но починили сборку на старом-старом CentOS 6.

https://discuss.python.org/t/python-3-10-4-and-3-9-12-are-now-available-out-of-schedule/14568

Переезд с BPO на GitHub Issues начнётся сегодня. Думаю, на выходных оба баг-трекера будут недоступны. Так что если вы вдруг обнаружите баг в питоне, лучше попридержите проблему до понедельника и зашлите её сразу же в GitHub Issues 🌝

https://discuss.python.org/t/github-issues-migration-status-update/14573

Вы же знаете, что по умолчанию для работы с текстовыми файлами Python использует кодировку UTF-8 на Unix, но не на Windows? Там он возьмёт системную кодировку, типа Win-1251, в зависимости от локали.

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

Это поведение было выбрано, чтобы Python вёл себя привычным для платформы образом и не было проблем с другими программами. Например, можно через Python создать текстовый файл, а затем открыть его в Блокноте, и увидеть там правильные буквы, а не "кракозябры" — в старых версиях Windows это было очень актуально. С другой стороны, это усложняет переносимость программ — нужно специально везде указывать кодировки явно, чтобы получить одинаковое поведение на разных платформах.

Сегодня уже ясно, что пластмассовый мир победил и юникод оказался сильней. Практически повсеместно используется UTF-8. Одна универсальная (пусть и не всегда компактная) кодировка куда практичнее, чем множество узкоспециализированных.

И в Python тоже обсуждается переход на UTF-8 везде по умолчанию. Даже на Windows. Пока что это лишь черновик, но идея годная, и я не удивлюсь, если предложение примут. В любом случае, произойдёт это не раньше версии 3.13.

Кстати, в 3.10 при помощи флажка уже можно включить ворнинги, и поймать все места, где у вас при работе с текстовым вводом-выводом не указана кодировка явно. Это подготовка к всеобщему переходу на UTF-8.

#pep #unicode

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

В 3.11 добавят тип LiteralString, который может принимать любые строки, собранные из строковых литералов. Можно взять любые литералы, как угодно их скомпоновать друг с другом, и в итоге всё равно получится тип, совместимый с LiteralString. Но если подмешать туда любую строку, которая не хранится в коде программы, а поступает извне, то это уже не может быть LiteralString.

hello = "Здравствуй"
world = "прекрасная планета"

# совместимо со StringLiteral, потому что строчка составлена целиком из литералов в коде
s1 = f"{hello}, {world}!"

# не совместимо, потому что примешивается что-то извне, не литерал
name = input("name: ")
s2 = f"{hello}, {name}!"

Зачем такой тип нужен? При помощи него можно запретить передавать в "опасные" функции, подверженные различного рода инъекциям, строки, включающие пользовательский ввод. Это просто будет ошибкой на уровне системы типов. Таким образом, написать уязвимый код с SQL, shell, XSS, SSTI или какими-либо ещё инъекциями станет немножко сложнее. Для этого всего лишь нужно, чтобы в библиотеках важные места были помечены этим типом, и, конечно же, чтобы пользователь время от времени запускал тайп-чекер. На выполнение программы это всё никак не влияет.

Пока что это предложение поддерживается только в тайп-чекере pyre.

https://peps.python.org/pep-0675/

#pep #typing

Кстати, да. Правильно произносить [ˈwukaʂ]. Где-то видел вариант произношения как woo cash. Даже не знаю, как это написать русскими буквами, но это либо "Укаш", либо "Вукаш".

Вот видео: https://www.youtube.com/watch?v=rCDVnyb8k-U

Многие уже приняли за норму форматирование кода разными тулзами (black) и сортировку импортов в алфавитном порядке с разбиением на группы (isort).

А что если начать сортировать ещё и весь остальной исходный код?

https://github.com/bwhmather/ssort

ssort сортирует функции и классы, ставя их после того, от чего они зависят. Получается, что вверху файла находятся самые низкоуровневые функции, от которых всё зависит, а внизу файла — самый главный высокоуровневый код. Прям как завещал дядюшка Боб.

> Makes old fashioned code navigation easier, you can always scroll up to see where something is defined, and reduces bikeshedding.

#formatter #tool

Ещё одна новость про форматирование.

Одна из популярных причин, почему люди не в восторге от идеи внедрить форматтер кода в свои старые проекты — это замусоривание истории изменений. Появляется царь-коммит, который изменяет весь код сразу, и git blame бессилен пробиться через него к более старым изменениям. Получается, с точки зрения Git, человек, запустивший Black, становится автором всего проекта 😅

Начиная с версии 2.23.0 (это 2019 год) Git поддерживает возможность игнорировать некоторые коммиты в git blame, что как раз и решает эту проблему.

Крутая новость в том, что GitHub теперь тоже в своём Blame View научился игнорировать такие коммиты. Создаёте специальный файлик, записываете туда хэши своих коммитов с форматированием кода и вуаля!

https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view

#formatter #github #git #blame #black

Если вдруг кому нужна такая же фича в локальном консольном Git или в GUI, типа PyCharm или VSCode, то вот как это делается:

git config --local blame.ignoreRevsFile .git-blame-ignore-revs

Нужно выполнить после клонирования репозитория. К сожалению, самостоятельно Git находить этот файл пока что не научился.

#formatter #git #blame #black

А если кому нужна такая же фича в веб-интерфейсе BitBucket, то голосуйте за нашего кандидата вот здесь:

https://jira.atlassian.com/browse/BSERV-12730

#git #bitbucket #blame #black

Для GitLab такая фича тоже обсуждается, ставьте свои пальцы вверх вот сюда:

https://gitlab.com/gitlab-org/gitlab/-/issues/31423

#git #gitlab #blame #black

Конфетку не желаете?

(На самом деле конфеты не существует. Мы живём в симуляции, птицы — это дроны, а конфета — это просто 3D-модель, нарисованная кем-то в Blender.)

https://www.reddit.com/r/Python/comments/rgaoy7/comment/hoiw67v/?utm_source=share&utm_medium=web2x&context=3

Вижу, что многие пользуются black, isort или как минимум форматируют код в PyCharm. Инструменты хорошие, но они ориентируются на устаревший PEP-8, поэтому в ближайшее время придётся подыскивать им замену.

Опубликован черновик нового стайл-гайда PEP-9001, который через какое-то время станет обязательным для соблюдения, поэтому рекомендую всем ознакомиться уже сейчас и присоединиться к обсуждению:

https://peps.pythondiscord.com/pep-9001/

#pep