Уже 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

Многие пользовались возможностью импортировать синтаксис из будущего (from __future__ import …), но задумывались ли вы когда-нибудь ОТКУДА на самом деле приходит этот синтаксис? Ведь если мы можем получить фичи из будущего, значит кто-то в будущем должен отправлять их в прошлое?

Документ описывает установку для отправки синтаксиса в прошлое на основе наработок по «потоковому накопителю» доктора Эмметта Брауна.

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

#pep

Vim-like браузер на питоне.

Ладно-ладно, это, конечно, не совсем правда. Там под капотом QtWebEngine, который по сути Chromium и написан он на C++. Тем не менее, вся обвязка вокруг непосредственно отображения страницы написана на питоне.

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

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

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

https://github.com/qutebrowser/qutebrowser

Миграция из BPO в GitHub Issues заняла больше времени, чем ожидалось, но она наконец-то завершена.

BPO переведён в read-only режим.

Новый питонячий баг-трекер теперь официально находится здесь: https://github.com/python/cpython/issues

Что думаю по этому поводу.

С одной стороны, использовать стандартные решения — это хорошо и удобно. Все уже привыкли использовать гитхаб. У большинства есть там аккаунты. Все уже научились писать свои мысли в маркдауне. Удобно ссылаться из пулл-реквестов в ишьюсы, и наоборот. Есть API, и уже написана куча разных скриптов и браузерных плагинов, которые позволяют делать с гитхабом практически что угодно. Есть собственная удобная CI платформа.

С другой стороны, централизация — это однозначно плохо. Появляется единая точка отказа. Хоть они в последнее время и няшки, но всё равно — Microsoft начинает иметь слишком много влияния над опенсорсом. Такие перекосы обязательно рано или поздно выльются в проблемы. Например, мир разоссорится ещё сильнее, в США придумают очередные какие-нибудь весёлые ограничения для жителей недружественных стран, а GitHub (американская компания) будет обязан подчиниться.

В любом случае — спасибо, что переехали не в Jira!

Опубликовали статистику скачиваний интерпретатора с python.org за последний год. Вычислено на основе access-логов.

Больше всего оттуда качают предсобранные установщики для Windows, но много и тех, кто скачивает просто исходники (это, вероятно, линуксоиды и маководы с pyenv и тому подобным). Чуть-чуть есть и людей, которые скачивают предсобранные установщики для macOS.

Python 2.7 держится по популярности примерно на уровне 3.6.

Для Windows самая популярная с большим отрывом версия интерпретатора сейчас — 3.10.

Но при этом в исходниках нет такого явного фаворита: качают все версии — и 2.7, и с 3.6 по 3.10 — примерно одинаково. Причём больше всего качают 3.7, а меньше всего 3.10. Может быть дело в том, что в современных линуксах обычно есть свежий питон, а более старые версии приходится откуда-то ставить? (А я обычно в любом случае ставлю все нужные мне версии из pyenv — системный питон лучше вообще не трогать, пусть спокойно себе лежит).

Там же в треде есть и ссылки на похожие исследования за 2020 и 2019 годы.

https://discuss.python.org/t/python-download-stats-for-march-2022/14908