Ещё одна новость, про помощь.

Сообщество помогло вывезти близких Сергея Сторчака из Украины и найти им временное жильё. Łukasz Langa даже поехал в Варшаву, чтобы лично их встретить и помочь обустроиться.

Из твиттера Сергея:

> My sister and her family are near the nuclear power plant, which is a strategic target. My young nephew is in Kyiv and may die in one of the battles. These are the people dearest to me, I live only for them and my mother.

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

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

https://www.reddit.com/r/Python/comments/t9dd6n/family_of_key_python_contributor_storchaka_has/

Вам всегда в питоне не хватало указателей и арифметики над ними? Держите, пользуйтесь, теперь такое есть! (Пожалуйста, не надо)

https://github.com/ZeroIntensity/pointers.py

Кстати, Python 3.10.3 вышел. Там багфиксы и исправления разных секьюрити проблем. Надо обновляться!

https://blog.python.org/2022/03/python-3103-3911-3813-and-3713-are-now.html

Обновился до macOS Monterey 12.3. Подтверждаю, Python 2 пропал.

К счастью, для того проекта, где он мне нужен, у меня уже было до обновления создано виртуальное окружение, и оно нормально работает 😅
Так что я пока ничего делать не буду. А вообще, говорят, можно поставить Python 2 из Homebrew.

#macos #python2

А вы знали, что attrs поддерживает Python 2.7? Точнее, теперь об этом уже стоит говорить скорее в прошедшем времени.

https://github.com/python-attrs/attrs/pull/936

#python2

В PSF в честь Pi Day (14 марта) объявили фандрайзер. Обратите внимание, какие забавные суммы они собирают!

https://psfmember.org/civicrm/contribute/transact?reset=1&id=37

да

В репо faster-cpython выложили результаты сравнения производительности ветки main (это будет 3.11) с 3.10. И по большинству бенчмарков оно и правда становится быстрее!

https://github.com/faster-cpython/ideas/blob/main/main-vs-310.rst

Недавно вышел 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