Хитрый Питон

В debian теперь перестанет позволять делать pip install не в виртуальном окружении (https://peps.python.org/pep-0668/). Мотивация - чтобы нельзя было (просто) заменить пакеты установленные apt-ом на пакеты из pypi.

С одной стороны выглядит как разумный шаг для большей стабильности системы, с другой стороны это неожиданное поведение для новичков на линуксе. Так-то, конечно, можно поставить свою отдельную версию питона и там pip будет ставить пакеты глобально, если вам зачем-то это нужно.

В Ubuntu это поведение будет поддержано уже в 23.04. Вот тут новость https://salsa.debian.org/python-team/packages/python-pip/-/blob/master/debian/NEWS

Небезызвестный Армин Ронахер - автор Flask - выложил свою замену pip/poetry/venv/pipenv/hatch и т.д. - `Rye. Написан на rust и явно под влиянием cargo. Выглядит довольно удобно - можно выбрать версию python, сам создает и мейнтейнит pyproject.toml, пакеты ставит с помощью pip-tools под капотом. В общем на странице проекта есть 10-минутное видео, где Армин показывает работу с rye.

Из минусов - похоже он не планирует активно заниматься проектом, поэтому возникает вопрос насколько можно его использовать за пределами личных проектов. Работает пока только на linux и mac. В общем буду посматривать, будет здорово если мы получим не еще один 100500-й менеджер пакетов, а популярный инструмент, который составит хорошую конкуренцию существующим.

Ссылка на репо - https://github.com/mitsuhiko/rye

PyPi анонсировали новую фичу для публикации пакетов - Trusted Publishers. Грубо говоря - это возможность использовать короткоживущие OIDC-токены вместо логина/пароля/токена для публикации пакетов на pypi.

Выглядит удобно, самый простой способ начать этим пользоваться - использовать готовый Github Action https://github.com/marketplace/actions/pypi-publish

Ссылка на блог - https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/

28 апреля в 14:00 делаем очередной прямой прямом эфир Moscow Python Podcast, где будем говорить об обучении программированию в целом и python в частности. В гости придет Артем Рудаковский, преподаватель в Лицее Академии Яндекса.

Обсудим:
→ за что взяться начинающему специалисту в первую очередь;
→ как сделать свой первый проект;
→ ресурсы, которые помогут изучить Python;
→ нужно ли всем изучать программирование.

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

Так получилось, что в апреле мне понадобилось апдейтить Django в двух проектах - один здоровенный монолит с 3.1 до 3.2 и маленький moscowpython.ru с 1.9 до 4.2. Как ни странно, переход 3.1->3.2 попил больше крови из-за кучи зависимостей и легаси кода, но рассказать я хочу не об этом.
Я хочу рассказать о небольшой библиотечке django-upgrade, которая оказалось очень полезной при обновлении. Ей нужно указать на какую версию ты хочешь обновиться, после чего она шерстит файлы проекта и заменяет всякие deprecated-штуки на их замену из новых версий - например переписывает использование url() на path() в urlconf-ах, заменяет NullBooleanField() на BooleanField(null=True) и все такое прочее. Полный список того, что она делает можно посмотреть в readme.
Итого — это штука, которая позволяет при обновлении не копаться в ченджлогах, а отдать некоторый кусок рефакторинга пир апдейте автоматике. Рекомендую посмотреть на нее, если вам нужно апгрейдить версию джанги.
Ссылка - https://github.com/adamchainz/django-upgrade

Внезапно резкие ребята из Sentry удалили пакет codecov с pypi. На редите плачут те, у кого из-за этого развалились пайплайны. Вроде как пакет давно выдавал deprecation warning, но кто их читает? 😉
Хорошо, что ребята из pypi заблокировали возможность сквоттинга названия пакета после его удаления. Иначе кто-нибудь шустрый и сообразительный вполне мог бы выложить что-нибудь прикольное с малварью внутри.
Я свои проекты проверил - у меня он нигде не используется. Проверьте у себя. Вот пост от codecov с извинениями и рекомендациями как правильно починить проблему https://about.codecov.io/blog/message-regarding-the-pypi-package/
Доброе утро 🙂

Отвечаем на вопросы про Python в прямом эфире
Завтра, 13 апреля в 14:00 по Москве встретимся решили сделать трансяляцию Moscow Python Podcast, полностью посвешенный ответу на вопросы зрителей. Попробуем новый формат 🙂

Оставляйте свои вопросы анонимно в форме или публично в комментариях к трансляции — https://www.youtube.com/watch?v=fd_xgN_zHvk
Присоединяйтесь к нам по ссылке!

Завтра, 7 апреля в 14:00 по Москве будем обсуждать новости питона за март в прямом эфире:

- LTS-релиз Django 4.2;
- Pandas 2.0;
- PyTorch 2.0;
- свежее исследование Django-экосистемы от JetBrains.
- предложение по ускорению list comprehensions;
- отклоненное предложение по аналогу node_modules в Python

Приходите поболтать, ставьте лайки и вот это все 🙂 https://www.youtube.com/watch?v=vtjmhIhdweo

Вышел LTS-релиз Django - 4.2. Long Term Support означает, что этот релиз будут поддерживать несколько лет, до 2026 года. Из интересных новинок:

- Реализовали поддержку psycopg3. Сейчас поддерживаются обе либы, но от psycopg2 планируют в будущем отказаться
- Добавили возможность оставлять комментарии для таблиц и полей БД
- На смену DEFAULT_FILE_STORAGE и STATICFILES_STORAGE приходит настройка STORAGES, которая позволяет объявлять столько файловых стореджей, сколько нужно
- In-memory file storage, удобная штука для использования в тестах, приятно учитывая, что dj-inmemorystorage уже несколько лет как перестала обновляться
- Минимальная версия postgres теперь - 12-я
- Еще больше поддержки асинхронности - asave(), adelete() и arefresh_from_db() для моделей, плюс aadd(), aclear(), aremove() и aset() для relation managers

И самое главное - добавили темную тему для админки. Все, кто не использовал Джангу из-за отсутствия темной темы, могут начинать использовать 🙂

Полный список изменений https://docs.djangoproject.com/en/4.2/releases/4.2/

Если вы с помощью pip ставите библиотеку по ссылке, например с гитхаба, то pip сохраняет информацию о том, откуда вы этот пакет поставили в файлик direct_url.json. В новом PEP 710 предлагают расширить эту практику на все пакеты и для пакетов, поставленных из репозиториев типа pypi. Т.е. сохранять для всех пакетов ссылку и хеш.

С одной стороны, это очень "внутреннее" изменение, которое может быть интересно разве что разработчиков менеджеров пакетов. С другой стороны, мне показалось это интересным, так как позволит лучше понимать что, как и откуда устанавливалось на проекте. Особенно в случае, когда используется несколько репозиториев (например pypi и свой) и имена пакетов могут совпадать.

Ссылка на pep https://peps.python.org/pep-0710/

Вышел pandas 2.0 релиз, который был во многом ориентирован на улучшение производительности. Что интересного:

- Если раньше pandas работал только поверх numpy, теперь можно выбрать в качестве бекенда apache arrow
- Работа с отсутствующими значениями и строками стала эффективнее при использовании arrow backend
- Copy-on-write - ленивое копирование, при котором реальное копирование данных откладывается до тех пор, пока мы не начнем изменять данные. Это уменьшит количество ошибок, когда меняя данные в срезе мы на самом деле меняем исходный фрейм и при этом не скажется на производительности, когда нам нужно только читать данные
- Числовые индексы теперь могут быть не только 64-х разрядные (`int64`, uint64, `float64`), но и любых других числовых типов
- У datetime и timedelta теперь можно указывать единицу измерения. Если раньше pandas приводил все к наносекундам, теперь можно явно указать что-то типа dtype="datetime64[s]"

Полный список изменений: https://pandas.pydata.org/docs/dev/whatsnew/v2.0.0.html

Если помните, несколько лет назад появилось предложение добавить в path папку __pypackages__ и ставить туда локальные пакеты по аналогии с node_modules. Так вот, после долгих обсуждений это предложение (PEP 582) таки отклонили.

Ставлю ссылку на пост-обоснование от steering council, но если коротко предложение завернули потому, что по факту оно решало только небольшой набор проблем с установкой пакетов. Но про более сложные задачи там сказано "переключайтесь на виртуальные окружения". Например, как ставить пакеты, в которых не только python-файлы, но и, скажем, бинарники.

Да, тем кто только приходит в язык это упростило бы жизнь, но до очень определенного предела и при попытке сделать что-то чуть более сложное им все равно бы пришлось переключаться на виртуальные окружения. А мы бы все получили еще +1 стандарт к итак довольно запутанному процессу управления пакетами в python. https://discuss.python.org/t/pep-582-python-local-packages-directory/963/430

В пятницу, 31 марта в 14:00 встретимся в прямом эфире Moscow Python Podcast с Мстиславом Казаковым, тимлидом в Usetech. Вместе с гостем обсудим:

• наблюдаемость(observability) сервисов;
• стандартизацию логов;
• подключение Elastic APM к Django-приложению;
• использование Openmetrics для выгрузки данных.

В ходе трансляции будем отвечать на вопросы и комментарии в прямом эфире. Присоединяйтесь по ссылке и ставьте колокольчик 😀, чтобы не забыть.

Ребята, которые делают Starlite - еще один интересный веб-фреймворк, написали чуть больше подробностей о версии 2.0. Что интересного обещают:

- они выпиливают pydantic как обязательную зависимость. Можно будет продолжать использовать его, но если нужна скорость, можно взять тот же msgspec
- добавили event bus - возможность отправлять и получать сообщения. Сейчас работает только с in-memory очередью, но к релизу обещают поддержку reddis/rabbitmq
- поддержка key-value хранилищ - in-memory, redis, файлы. Теперь не нужно придумывать свою реализацию для, скажем, кеш-бекенда

Прямо интересно наблюдать за проектом, развивается активно и притаскивают интересные фичи. Полностью анонс можно прочитать на reddit https://www.reddit.com/r/Python/comments/122ld24/starlite_updates_march_22_20_is_coming/

Наткнулся на интересную либу - MegaMock, которую позиционируют как более удобную замену для стандартного unittest.mock. В чем удобство:

- делает autospec по аналогии с create_autospec сразу по умолчанию
- принимает на вход не текстовую строку, а прямо объект или функцию, это удобно если делать например рефакторинг средствами IDE
- убирает необходимость в штуках типа with mock.patch() потому что сразу патчит сам и везде
- при патчинге можно для отдельных методов оставлять реальную логику вместо мока

В общем выглядит интересно, попробую в пет-проджект затащить и посмотреть так ли все хорошо https://github.com/JamesHutchison/megamock

List comprehensions (выражения типа [x for x in iterable]) в питоне обычно сложновато даются новичкам. Но стоит один раз разобраться с синтаксисом, как понимаешь, насколько это удобный инструмент. Более того, они быстрее чем .append() в список в цикле.

И вот в новом PEP 709 предлагают оптимизировать их работу. Сейчас при переводе list/dict/set comprehension в байткод происходит создание вложенной функции и ее исполнение. Авторы PEP предлагают не создавать эту дополнительную вложенную функцию, а сразу писать в байткоде ее содержимое (inline). Это должно быть безопасно, так как в случае list comprehention мы не можем стандартными средствами в процессе его выполнения как-то повлиять на переменные внутри.

У этого подхода есть большой плюс - ускорение исполнения подобных выражений на 11% на тестах. Из минусов - в трейсбеках больше не будет пункта listcomp и при трейсинге/профилировании не будет видны вход в comprehension и выход из него. На мой взгляд плюсы заметно перевешивают минусы, надеюсь этот PEP примут и внедрят в одном из ближайших релизов.

Ссылка https://peps.python.org/pep-0709/

Сегодня будет очередной Moscow Python Meetup, к созданию которых я когда-то приложил руки. Даже если вы не в Москве, можно посмотреть трансляцию https://www.youtube.com/watch?v=v3buzDmoHxA

В программе:

* Лучший язык — это… или Пайтон против Суслика (Евгений Соколов, YADRO)
* Кто такой syslog, зачем читать RFC-* и причём тут Django (Максим Безруков, Ред Софт)
* и секретный доклад от Николая Маркова в Aligned Research Group

Вышло свежее исследование Django-экосистемы от JetBrains. Из интересного:

- за 2022 многие переехали с о старых и неподдерживаемых версий на 3.2/4.1
- забавный пассаж про "3.1 и ниже используют в основном опытные разработчики, а новички выбирают послденюю версию". Подозреваю, что на самом длеле это история о том, что когда ты работаешь с большой легаси кодовой базой обновляться - это каждый раз квест
- htmx набирает популярность и похоже отжимает пользователей у React (1 место) и jQuery (2 место)
- 46% разработчиков прописывают аннотации типов
- black/isrt/pre-commit неплохо прибавили в популярности

Ссылка https://lp.jetbrains.com/django-developer-survey-2022/

Python meetup (Online)

1. Real-time аналитика в Uchi.ru - как смотреть сложные метрики здесь и сейчас - Андрей Скиба, Uchi.ru

В докладе рассказывается об архитектуре системы real-time аналитики, разработанной в Uchi.ru, а также о примененных в ней подходах и технологиях.

2. FastAPI с нуля до production-ready образа - Алексей Шарыпов, VK

Поделюсь опытом, как запустить FastAPI приложение в продакшне. На простых примерах покажу как собрать контейнер с использованием Poetry.

3. Введение в функциональное программирование на Python - Алексей Каньков, Revizto

Основы функционального программирования и его применению в Python для разработчиков среднего и продвинутого уровня, которые хотят расширить свои знания в этой области.

➖➖➖

🗓 29 марта, начало в 19:00 мск, Среда

🌐 ОНЛАЙН

✅ Регистрация на мероприятие

Последние несколько месяцев регулярно выходят новости в стиле "на pypi залили еще 100500 пакетов с названиями, похожими на популярные библиотеки и злодейским кодом внутри". Эта схема как-то работает потому, что особенно новички часто слышат где-то название библиотеки и ставят ее, не посмотрев внимательно, что это за код.

На realpython.com вышла статья, которая рассказывает том, как оценить качество либы перед тем, как начать ее использовать. В принципе ничего сложного, но как много людей, к примеру, обращают внимание на то, под какой лицензией выпущена библиотека?

Итак коротко, что они советуют:

- Посмотреть внимательно страницу пакета на pypi, кто автор, сколько было релизов, когда был последний релиз, какой Development Status - если там planning или alfa - точно ли вы хотите тащить к себе подобный код?
- Посмотреть страницу пакета на Libraries.io, это даст чуть больше информации чем pypi
- Заглянуть в репозиторий на github/gitlab и оценить активность разработки, количество issues, качество readme и т.д.
- Посмотреть, что за лицензия у либы. Это не очень важно для маленьких проектов, но если вы пишете коммерческий софт, проблемная лицензия может потребовать срочно менять библиотеку если к вам придет, например, аудит при получении инвестиций или заключении крупного договора. Поверьте, выпиливать либу проросшую корнями в код может быть очень, хм, интересным опытом.

В общем думайте, что вы скачиваете из интернетов (с) https://realpython.com/python-package-quality/