Недавно появился черновик PEP 665 про стандартный способ хранить и описывать lock-файлы для установки зависимостей. Этот документ, судя по всему, является реакцией на тот зоопарк решений, который сообщество породило в попытках решить эту проблему. Например, сейчас для точного воссоздания окружения используются следующие файлы:

* pip-tools создаёт requirements.txt с хэшами всех зависимостей;
* pipenv создаёт Pipfile.lock;
* poetry создаёт poetry.lock.

А после PEP 655, если он будет принят, возможно, у всех этих инструментов будет общий формат описания зависимостей в папочке pyproject-lock.d, и они будут конкурировать не при помощи своих форматов описания зависимостей, а другими способами — кто лучше и быстрее резолвит граф зависимостей, чем удобнее пользоваться, и т.д. А ещё было бы логично, если бы и сам pip умел устанавливать зависимости из этих lock-файлов, так чтобы не приходилось на проде иметь ничего лишнего.

Если интересуетесь cloud-based IDE, то можно попробовать Gitpod. Они делают примерно то же самое, что и GitHub Codespaces, только начали они раньше. Тоже VS Code в браузере с бэкендом где-то в облаке. Опенсорс, можно сделать self-hosted. Доступно всем желающим, можно пользоваться уже сейчас.

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

Насколько я понял, пока что этим можно пользоваться только через браузер, т.е. нельзя подключиться из локальной VS Code.

P.S. Чувствую, этому сервису придётся очень тяжко, когда GitHub Codespaces выйдут из беты.

https://www.gitpod.io/blog/cloud-based-development-for-everyone

Я начинаю проникаться всё большей симпатией к идее эфемерных облачных окружений для разработки.

Мы уже давно привыкли описывать всю инфраструктуру в виде кода. Это удобно и позволяет быстро разворачивать новые типовые сервера, так что сами по себе отдельные сервера перестали быть ценностью. Если вдруг катастрофа, то всё всегда можно удалить и развернуть заново. Важен не сам сервер, важен рецепт, как этот сервер развернуть. Если призадуматься, то машина разработчика — это тоже своего рода инфраструктура, и её тоже можно (и нужно!) описать в виде кода, и воссоздавать/пересоздавать по запросу.

Это же невероятно круто, когда новый человек в компании может за 10 секунд получить готовое настроенное окружение для разработки. Все зависимости есть, тесты проходят, нужные плагины для IDE установлены и настроены. Берешь и сразу же начинаешь разбираться с кодом, а не тратишь три дня на клонирование огромных репозиториев, установку и компиляцию всех зависимостей. Знакомо ведь это чувство, когда нужно собрать какую-то конкретную лохматую версию какой-то всратой библиотеки из исходников с патчами? И эти скрипты почему-то работают на одной машине, но не работают на другой, и никто на самом деле не понимает почему.

А если вдруг твоё эфемерное окружение для разработки вышло из строя, то без проблем — просто создай новое, и через 10 секунд будешь готов продолжить работу.

Постоянно наступаю на проблему, что при переключении между ветками в Git забываю обновлять зависимости. Переключаешься на новую ветку — тесты не работают, линтеры красные. "Ах, ну да, эта ветка отстаёт от мастера на две недели, здесь с такими версиями библиотек ничего работать не будет". Запускаешь свой pipenv --rm && pipenv sync --dev. Это минуты на три. Выпадаешь из потока и идёшь запаривать очередную кружку кофе. А ведь можно было бы просто закрыть один редактор и открыть другой, где всё уже настроено для той конкретной ветки, которая тебе нужна.

И GitHub Codespaces, и Gitpod в фоне постоянно собирают (prebuild) окружения, чтобы можно было взять, и как можно быстрее начать пользоваться. На самом деле, я пока в восторге именно от эфемерности этих окружений для разработки. То, что они работают в облаке — это не так уж и важно. Просто так проще организовать всю эту систему.

https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/

Django Software Foundation и JetBrains проводят опрос про экосистему вокруг этого популярного веб-фреймворка. Практикующих и сочувствующих призываю принять участие.

https://www.djangoproject.com/weblog/2021/aug/04/2021-django-developers-survey/

#jetbrains

Lambda + Python 3.9:

https://aws.amazon.com/blogs/compute/python-3-9-runtime-now-available-in-aws-lambda/

#Lambda

Чистый код на Python.

Эта статья содержит в себе краткий пересказ принципов, которые позволят писать идиоматичный, читаемый и поддерживаемый код. Примерно как конспект всех книг дядюшки Боба, но сразу же применённый к Python.

https://testdriven.io/blog/clean-code-python/

Как работают импорты в Python?

Ух, давненько я не читал такой жести, это прям сплошное мясо. Думаю, эта статья заслуживает однажды быть напечатанной в составе какой-нибудь книги. Очень много подробностей того, как устроена система импортов в Python. Я понимал, что эта система сложнее, чем я себе представляю, но не представлял насколько. Возможно, эти знания помогут мне меньше страдать с хаотичным перекладыванием файлов по папкам так, чтобы оно всё импортировалось в будущем.

Однозначно рекомендую эту серию статей "Python behind the scenes" к внимательному изучению, оно того стоит.

https://tenthousandmeters.com/blog/python-behind-the-scenes-11-how-the-python-import-system-works/

Brett Cannon запилил запускальщик питона py, который всегда запускает последнюю, самую свежую среди установленных версию. Это решает проблему, когда алиасы python/python3 перезатираются при установке очередной версии питона, так что они указывают не на самую новую версию питона, а на недавно установленную. В мире Windows подобная штука существует уже лет 10 и устанавливается по умолчанию, а вот теперь такое же есть и для Unix-систем.

Я никогда не страдал от проблемы перезаписывания алиасов python/python3, потому что пользуюсь менеджером версий asdf и сам контролирую, на какую версию ссылаются эти алиасы. Да, и pyenv тоже умеет точно так же.

Для меня, пожалуй, самым полезным применением этого py будет то, что он умеет находить виртуальные окружения, и использовать их без активации, так что вместо:

source .venv/bin/activate
python -m pip install httpx

можно писать вот так:

py -m pip install httpx

Написано на Rust.

https://snarky.ca/introducing-the-python-launcher-for-unix/

В Python 3.10 добавлены две новые встроенные функции aiter() и anext(), которые наконец добавляют возможность полноценно контролировать асинхронные итераторы и генераторы без вызовов dunder-методов. Синхронный и асинхронный миры становятся чуть более симметричными.

https://twitter.com/1st1/status/1374499776570347521

Первый доклад там по сути является пересказом событий и выступлений с Language Summit 2021. Там вообще было показано и сказано много интересного. Ускорение питона нынче самая популярная тема. Горячий выдался саммит, и сообществу наверняка понадобится какое-то время, чтобы всё это качественно впитать и осознать.

Вспомнил всё ещё разок и заодно законспектировал. Вот вам пересказ пересказа.

🐍 Making CPython faster
* Гвидо собрал команду внутри Майкрософт, и они будут работать над ускорением CPython;
* конечная цель — x5 ускорение в течение 4 лет;
* в 3.10 появятся первые оптимизации из этой серии, а 3.11 уже якобы должен работать примерно в два раза быстрее;
* всё это будет достигнуто без жертв со стороны обратной совместимости и мирного населения.

🐍CPython Improvements at Instagram
* внутри Instagram развился собственный форк CPython под названием Cinder, где они экспериментируют с различными подходами по улучшению производительности;
* в общей сложности, получилось ускорить CPython на 20-30%;
* среди применённых оптимизаций — различные срезания углов в асинхронном коде, оптимизация словарей;
* сделали JIT;
* исходники форка доступны на гитхабе, но поддерживаться оно не будет; вместо этого, они будут пытаться пропихнуть удачные оптимизации в апстрим CPython;
* они там в инстаграме совсем ударились в форки питона, поэтому кроме Cinder у них есть ещё один форк под названием Pyro, где упор сделан на более оптимальную работу сборщика мусора.

🐍HPy — Present and Future
* в разработке находится HPy — новый API/ABI для работы с интерпретатором из нативного кода, например, из библиотек на C;
* обещают, что это сделает PyPy и Python внутри GraalVM быстрее;
* в перспективе это ускорит и CPython, но не сейчас.

🐍 Progress on Running Multiple Python Interpreters in Parallel in the Same Process
* субинтерпретаторы в перспективе решат проблему GIL, т.е. позволят эффективно утилизировать несколько процессорных ядер без создания новых процессов в ОС;
* в синтетических тестах субинтерпретаторы работают чуть медленнее, чем мультипроцессинг, но это пока что лишь прототип, так что ок;
* синхронизацию между субинтерпретаторами планируется сделать через что-то, очень напоминающее каналы в Go.

#конспект

Sebastián Ramírez (@tiangolo) выпустил новый хит — SQLModel ✨

Эта библиотека решает проблему дублирования кода моделей. Представьте, что вы используете FastAPI. Вам нужно определить модель данных один раз в стиле pydantic, чтобы провалидировать пользовательский ввод. Вы также используете SQLAlchemy ORM, поэтому вы определяете практически точно такую же модель в стиле SQLAlchemy, чтобы описать таблицу в базе.

Больше так делать не придётся, потому что классы SQLModel — это и модели pydantic, и таблицы алхимии одновременно! ✨🎉

Это всё бесшовно интегрируется как с экосистемой вокруг pydantic, так и со всем, что связано с алхимией. Как всегда, везде активно используются тайп-аннотации, так что редакторы и IDE поют от радости песни. Документация, как всегда, заслуживает отдельного упоминания — Себастьян в этом плане хорошо завысил планку моих ожиданий, и на худшую документацию я теперь просто не согласен!

Ставьте звёздочки, выведем этот репо в тренды на GitHub 😅

https://github.com/tiangolo/sqlmodel

🐍 Привет, питоняги!

Pytup уже завтра!
Начало в 18-00 по МСК, онлайн.
Регистрируйтесь, ссылочка на трансляцию придет вам на почту

🤗 Вова покажет нам как дружить типы и ide
🧬 Надя покажет как она умеет "готовить" мутации
🗞 Напоследок узнаем свежие новости из мира питона от Андрея

ЗЫ запись будет, да 🎥

Это уже сегодня, если что!