Находки в опенсорсе
10.6K subscribers
11 photos
1 video
3 files
816 links
Привет!

Меня зовут Никита Соболев. Я занимаюсь опенсорс разработкой полный рабочий день.

Тут я рассказываю про #python, #c, опенсорс и тд.
Поддержать: https://boosty.to/sobolevn
РКН: https://vk.cc/cOzn36

Связь: @sobolev_nikita
Download Telegram
PEP-797: Иммортализация произвольных объектов

- Ссылка на черновик PEP: https://github.com/python/peps/pull/4497
- Оригинальный PEP-683 с Immortal объектами: https://peps.python.org/pep-0683

Продолжаем про будущее субинтерпретаторов! Да, что-то меня увлекла данная тема :)

Как делиться объектами без копирования данных в субинтерпретаторах?

Чтобы легко делиться объектами между субинтерпретаторами, необходимо, чтобы они были полностью иммутабельными. Полностью. Не с точки зрения питона, а с точки зрения C.

Даже если вы будете делиться объектами, которые внешне нельзя изменить, то все еще будет один очень важный нюанс.

Напомню, что объект питона с точки зрения C выглядит так (упрощенно):


struct PyObject {
Py_ssize_t ob_refcnt;
PyTypeObject *ob_type;
};


И вот тот самый ob_refcnt все время меняется. Буквально в любом C коде все время вызовы Py_DECREF и Py_INCREF. Без изменения счетчика ссылок невозможно выполнить никакой код. И буквально все части питона содержат вызовы, которые уменьшают или увеличивают счетчик ссылок во время работы программы.

Следовательно, мы можем словить гонку данных.
Чтобы гонки не было, мы не должны менять ob_refcnt. А чтобы его не менять, нам нужно, чтобы объект был бессмертным: жил на протяжении всего времени жизни программы и потом был правильно собран.

Что такое вообще Immortal объекты?

Ровно как я и писал выше – объекты, которые не участвуют в подсчете ссылок и живут, пока программа не завершится. Что-то вроде static в C и 'static в Rust.
Внутри питона есть несколько мест, которые нам интересны с данной точки зрения:


#define _Py_IMMORTAL_REFCNT_LOCAL UINT32_MAX


То есть – объект Immortal, когда у него просто очень большой refcnt. Что легко проверить:


>>> import sys
>>> sys.getrefcount(None)
3221225472

>>> x = None # он не будет меняться при создании новых имен:
>>> sys.getrefcount(None)
3221225472


И вот почему:


static inline Py_ALWAYS_INLINE void Py_INCREF(PyObject *op)
{
if (_Py_IsImmortal(op)) {
_Py_INCREF_IMMORTAL_STAT_INC();
return;
}
op->ob_refcnt++;
}

static inline Py_ALWAYS_INLINE void Py_DECREF(PyObject *op)
{
if (_Py_IsImmortal(op)) {
return;
}
if (--op->ob_refcnt == 0) {
_Py_Dealloc(op);
}
}


Когда объект "immortal", то с ним и не нужно проводить никаких доп операций.

Как предлагается делать свои?


import sys

admin = User('admin')
sys._immortalize(admin)
assert sys._is_immortal(admin)


Все! Теперь объект admin будет жить до конца программы. И его можно будет использовать в разных субинтерпретаторах без копирования:


>>> from concurrent import interpreters
>>> interp = interpreters.create()
>>> interp.prepare_main(admin=admin)
>>> interp.exec('print(admin)')
'<User: admin>'


Поверх такого АПИ, скорее всего, будет какое-то красивое АПИ. Нужно будет следить, чтобы бессмертные объекты не были слишком большими / их не было слишком много. Ну и подготовить их логически тоже необходимо.
Итого: иммутабельные объекты, субинтерпретаторы, полная параллельность. Да у нас, что, Erlang?!

Обсуждение: как вам данная фича?

| Поддержать | YouTube | GitHub | Чат |
160👍32🔥11🤔6💩3🕊3🤡3😁1🤯1
Снимок экрана 2025-07-25 в 16.38.01.png
454.8 KB
Делаем бесплатный курс по vscode?

Довольно часто последнее время наблюдаю, как программируют другие люди. На собесах в своем окружении, в паре со мной, на ютюбе и тд. И вот что я замечаю. Очень много людей страдает от базовых вещей, которые можно сделать простыми и удобными. Я хочу помочь.

Тем более видосы с нарезкой моего подкаста на данную тему с @t0digital собрали много обсуждений и даже возмущений. А значит – тема горячая :)

Будем делать из второй картинки третью.

О чем поговорим?
- Почему DX важен?
- Почему vscode, а не vim / pycharm / emacs / тд. И как применить такие же подходы к другим средам
- О минимализме. Для успешной работы вам нужно меньше инструментов, а не больше
- О том, как сделать минимальное количество полезных горячих клавиш, которыми вы реально будете пользоваться
- Как навигироваться по коду, файлам, важным местам в проекте
- Какие принципы позволят вам сделать свой уникальный рабочий сетап, который удобен вам
- Как можно делать свои крутые инструменты, как пример для работы со сложными кейсами в git: https://github.com/sobolevn/fzf-simple-git
- Как писать свои темы, плагины. И когда их не писать

Будет крайне полезно, чтобы писать код быстрее и проще.

Мои конфиги за ~10 лет работы всегда можно посмотреть тут: https://github.com/sobolevn/dotfiles

Собираем донат goal на +16 человек – и начинаем! Все будет бесплатно и на ютюбе. Подписка на https://boosty.to/sobolevn стартует со 100 рублей.

Холивар про IDE объявляется открытым в комментах 🌚
53👍25754🔥47👎9🤡4💩3👏2😱1👌1🕊1
Находки в опенсорсе
Анонс FishITStream (да, аллюзия на FastStream) Мы с пацанами решили, что если и делать стримы по программированию, то сразу стримы с рыбалки. Потому что нет ничего лучше, чем говорить про программирование с рюмкой чая да на природе, глядя на озерцо. Кто…
Находки на рыбалке: FastStream

https://www.youtube.com/watch?v=Qf4r8xV-YNk

Сгоняли с @fastnewsdev на рыбалку: поговорили про FastStream, пожарили мясо, обсудили проблемы разработчиков при работе с очередями / брокерами сообщений.

В своем первом посте мы уже знакомились с базовыми фичами FastStream'а, но для тех, кто пропустил, напоминаю: FastStream – аналог FastAPI, но для работы с событиями в брокерах / очередях.

Пример:


from faststream import FastStream
from faststream.kafka import KafkaBroker

broker = KafkaBroker("localhost:9092")
app = FastStream(broker)

@broker.publisher("another-topic")
@broker.subscriber("first-topic")
async def handle(user: str) -> str:
return f"Hi, {user}!"


Что делает данный код? Читает сообщения из first-topic, парсит из них поле user типа str, выполняет логику обработки, отправляет новое сообщение в another-topic. Просто? Удобно?

Что нам дает такой код?
- Декларативное описание, чего мы хотим. Не надо руками создавать коннекты и рулить потоком выполнения
- AsyncAPI документацию (аналог OpenAPI в вебе)
- Удобное тестирование
- Кучу других плюшек!

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

Внутри видео обсудили:
- Детали работы DI фастстрима
- Встроенное Observability
- Open Tracing
- Сообщество фреймворка (тут не будет проблемы "одного автора", сообщество живет!)
- Отличия от Celery: когда брать что?

Репозиторий: https://github.com/ag2ai/faststream
Документация: https://faststream.ag2.ai

Обсуждение: используется ли в ваших проектах асинхронная архитектура? Как вы работаете с событиями?

| Поддержать | YouTube | GitHub | Чат |
569👍36🔥16🤡5💩3🥰1
Находки в опенсорсе
Снимок экрана 2025-07-25 в 16.38.01.png
minimal vscode: открываем окна

https://www.youtube.com/watch?v=frZkPK_1Ui4

Нет, не от духоты, ее в видео как раз не будет 🌚️️️️
Видео короткое, динамичное, практичное.

Перед тем как учиться пользоваться vscode, необходимо:
1. Её поставить
2. Научиться её открывать
3. Располагать её на рабочем пространстве

В видео поговорили про:
- Brewfile и синхронизацию программ / плагинов
- Hotkey managers на примере https://github.com/koekeishiya/skhd
- Тайловые менеджеры окон: https://github.com/rxhanson/Rectangle
- Красивости вроде https://topnotch.app и https://hazeover.com

Все материалы для всех операционных систем тут: https://github.com/sobolevn/the-best-python-course/blob/main/minimal_vscode/links/1-open-vscode.md

Большое спасибо за такой отклик и поддержку 🧡, видео про отключение лишних панелей навигации уже в работе. Скоро будет!

Обсуждение: какие тайловые менеджеры используете вы?

| Поддержать | YouTube | GitHub | Чат |
17117👍36🔥21💩5🤡4🎉1🕊1
minimal vscode: убираем Activity и Side Bars

https://www.youtube.com/watch?v=wxbifNb1Q1o

Одни из главных потребителей места на мониторе: Activity Bar и Side Bar.
Их настолько просто убрать, чтобы оставалось больше места для кода, что я не вижу причин НЕ делать так.

- В несколько хоткеев сделаем столько же (и даже больше, учитывая новый отдельный Outline View)
- А еще отцентрируем Command Palette, чтобы было удобнее
- Покажу, почему Side Bar лучше иметь справа, а не слева от кода
- Прячем Side Bar, когда он нам не нужен (почти всегда)
- Покажу своих котов 🐈

Короткое, но максимально содержательное видео.

А что дальше по контенту?

На неделе будет большой пост из цикла "отвечаем на любимые вопросы с собесов": поговорим про то, как создаются объекты. PyObject_New, PyObject_NewVar, аллокаторы, изменяемость и неизменяемость. Поговорим: чем мутабельность int отличается от мутабельности tuple и list. Спрашивали ли вас такое? Считаете ли вы такой вопрос вообще полезным?

А еще скоро будут видео с прошлого митапа PythoNN! Три очень крутых доклада.

Следом будет продолжение "Лучшего курса по Питону" – устройство memoryview, полезнейший тип данных в питоне, который незаслуженно часто забывают.

Потом вернемся к чистке vscode от ненужного.

Если нравится такой план, не забудь поддержать :)

Обсуждение: пользуетесь ли вы Activity / Side Bar? Какие у вас самые популярные варианты использования данных инструментов?

| Поддержать | YouTube | GitHub | Чат |
1🔥82👍2211💩4🤡4
Используем ИИ для ревью кода

Сейчас довольно много говорят про написание кода при помощи ИИ, но меньше говорят про другой тип агентов (который лично мне нравится больше): ревью и анализ кода.

Ребята из GitVerse не так давно выпустили данную фичу, она доступна для всех. Я воспользовался возможностью и потестил.

Документация: https://gitverse.ru/docs/ai-agents/gigacode-agent

Методология проверки

Полный репозиторий: https://gitverse.ru/sobolevn/ai-code-review

Я придумал много разных типов ошибок и написал специально 🌚 плохой код на питоне. Вот он: https://gitverse.ru/sobolevn/ai-code-review/content/master/ai_code_review/example.py

- Небезопасный Python код: subprocess.run([user_input, ...])
- Плохое имя переменной: moy_lubimiy_film = '{"album_id": 1, "next_song": 2}'
- Сложный Python код в функции complex_code
- Затирание встроенного в Python имени: input
- Использование Any без явной причины: input: Any
- Неправильная аннотация типа данных: x: int = 'a'
- Логическая ошибка: if subvalue in seen
- Использование несуществующей переменной: missing_var
- Плохо отформатированный Python код: my_unformatted_list
- Некорректный порядок импортов: from typing import Any
- Небезопасная и устаревшая зависимость django@1.9 в pyproject.toml

Далее, я проверил, можно ли вообще статически найти ошибки, которые я заложил?
Я сделал GitVerse Actions файл, который запускает mypy, wemake-python-styleguide, ruff, safety.
И удостоверился, что они могут найти все ошибки, кроме одной проблемы из двух самых сложных во всем программировании:
- Плохое имя переменной: moy_lubimiy_film = '{"album_id": 1, "next_song": 2}'

Данная ошибка будет baseline для нашего ИИ.

Ревью при помощи ИИ

Чтобы ревью случилось, нужно просто добавить giga-code-agent в качестве ревьюера.
Что он делает?
1. Делает описание PR, если его нет. Там кратко перечисляет тип PR, ключевые изменения, важные технические детали. Удобно! Часто такие PRы просто раньше были пустые
2. Делает ревью. Описывает найденные проблемы. Учитывает тесты, которые отвечают за изменения. Действительно находит многие проблемы. От типизации до оформления. В текстах README.md нашел несколько ошибок. Но! Очень важно: находит не все ошибки
3. Делает советы по изменениям. Пока они оставляют желать лучшего. Но изменения по форматированию - я бы принял, остальные - нет
4. Можно уточнять что-то при помощи команды /ask

Итог: найдено 6 (или 3 в зависимости от способа запуска) ошибок. Что уважаемо, учитывая, что было 0 конфигурации, 0 интеграций. Надеюсь, дальше будет еще лучше :)

Наша baseline ошибка, кстати, была найдена, когда я явно задал контекст.

Вывод: используйте ИИ ревью вместе с другими инструментами статического анализа.
Полный отчет со всеми подробностями по ссылке.

Обсуждение: доверили бы вы ревьюить свой код ИИ?
👍79🤡4720🔥15🤔5😁3💩3🕊2🤯1
Большая бесплатная Python конференция в Нижнем Новгороде!

У меня хорошая новость. Делаем бесплатную конфу по питону, пригласили топовых специалистов: core-разработчиков, контрибьюторов, организаторов разных комьюнити движух, специалистов из индустрии. И все – участники нашего чата. Как же так получилось 🌚

Вот такой список докладов:

- Подопригора Кирилл, CPython core dev, Evrone: Кто такой CFG в CPython, и какую роль он выполняет?
- Хитров Николай, организатор @peer_2beer, Точка Банк: Проектирование — это когда чувствуешь, а не какие-то там циферки
- Ильиных Илья, организатор @spbpythonnews, блоггер @kydavoiti: Vim — это метаредактирование
- Джалаев Давид, Газпром-нефть ЦР: Continuous profiling
- Порядин Алексей, участник @pytho_nn: AI-агенты в каждый дом
- Мирянов Сергей, CPython contributor, РН-Технологии: Внутреннее устройство сборки мусора в CPython 3.14+
- Неретин Степан, CPython contributor, Postgres Professional: Своя файловая система за 5 минут на Python
- Ефимов Михаил, CPython contributor, X5 Tech: Генератор байткода и байткод генератора

Ну мощь же 💪
Да, конференции можно делать и не за 50 тыщ за билет.

А еще будет много доброго общения, обсуждения кишочков питона, настолки и тусовка до утра :)
Идеальный день.

Бронируйте дату! Если давно хотели побывать в Нижнем – вот идеальный повод. Буду рад всех видеть лично!

📍 Когда: 20 сентября 2025 года
📍 Где: ул. Нижне-Волжская набережная, 11, «Академия Маяк» им. А.Д. Сахарова

Регистрация обязательна: https://dev.itgorky.ru

| Поддержать | YouTube | GitHub | Чат |
10🔥136👍2112💩3
Три типа объектов в Питоне

В питоне часто любят обсуждать "мутабельные" и "иммутабельные" объекты, но крайне редко объясняют, в чем же на самом деле разница. Сегодня мы посмотрим на такое со стороны C.

PyObject

Все мы знаем, что в питоне все объект или PyObject *, который упрощенно выглядит так (в FT сборке он посложнее):


struct _object {
Py_ssize_t ob_refcnt;
PyTypeObject *ob_type;
}


То есть: у нас есть только счетчик ссылок на объект и указатель на его тип. Первое меняется очень часто, если объект не immortal. Второе тоже можно менять в некоторых случаях:


>>> class A:
... __slots__ = ()

>>> class B:
... __slots__ = ()

>>> a = A()
>>> type(a)
<class '__main__.A'>
>>> a.__class__ = B
>>> type(a)
<class '__main__.B'>


Получается, что большинство объектов мутабельные уже на данном уровне.

Но, в целом есть три типа объектов, разные по уровню мутабельности:
1. Такие как None: ob_refcnt не меняется (immortal), тип менять нельзя, ведь Py_TPFLAGS_IMMUTABLETYPE установлен (static type), размер неизменный 0 для всех потенциальных значений
2. Такие как int: ob_refcnt может меняться для больших чисел (маленькие инты - immortal), тип менять нельзя, размер нельзя менять, но он будет разный для разных чисел:


>>> sys.getsizeof(1)
28
>>> sys.getsizeof(10000000000000)
32


3. Такие как list: ob_refcnt всегда меняется, тип менять нельзя, размер меняется

Отдельно нужно отметить, что пользовательские классы обычно еще более мутабельны, потому что их тип менять можно.
Но, вопрос в другом: а где вообще хранится размер объекта и его внутренности? Раз в PyObject ничего такого нет.

C-API

В C-API питона есть два полезных макроса: PyObject_HEAD для объектов фиксированного размера и PyObject_VAR_HEAD для объектов, которые могут менять размер.


struct PyVarObject {
PyObject ob_base;
Py_ssize_t ob_size; /* Number of items in variable part */
};

#define PyObject_HEAD PyObject ob_base;
#define PyObject_VAR_HEAD PyVarObject ob_base;


Хотим поменять размер объекта? Увеличиваем ob_size, аллоцируем новую память (если нужно) под новые объекты внутри.

Итоговые объекты используют примерно такую логику:


typedef struct {
PyObject_VAR_HEAD
/* Vector of pointers to list elements. list[0] is ob_item[0], etc. */
PyObject **ob_item;

/* ob_item contains space for 'allocated' elements. The number
* currently in use is ob_size.
*/
Py_ssize_t allocated;
} PyListObject;


То есть: на самом деле все объекты list (и многие другие) не просто PyObject, они:
- Имеют свой собственный тип: PyListObject
- Имеют общую абстракцию для размерности: PyVarObject
- Имеют общую абстракцию для типа и счетчика ссылок: PyObject

Я сделал небольшой очень упрощенный пример. Там я показываю в том числе, как происходит каст одного типа поинтера в другой в C.

Итог

1. None не имеет внутреннего состояния вообще (не использует ничего)
2. int может иметь разный размер, но не может изменяться, потому использует PyObject_HEAD (раньше был PyObject_VAR_HEAD, там сложная история):


typedef struct _PyLongValue {
uintptr_t lv_tag; /* Number of digits, sign and flags */
digit ob_digit[1];
} _PyLongValue;

struct _longobject {
PyObject_HEAD
_PyLongValue long_value;
};


3. list может иметь разный размер и может изменятся, потому использует PyObject_VAR_HEAD, как я показывал выше

Обсуждение: как вы думаете, как работает len() для list?

| Поддержать | YouTube | GitHub | Чат |
6👍7421🔥4💩4🕊1
Находки в опенсорсе
minimal vscode: убираем Activity и Side Bars https://www.youtube.com/watch?v=wxbifNb1Q1o Одни из главных потребителей места на мониторе: Activity Bar и Side Bar. Их настолько просто убрать, чтобы оставалось больше места для кода, что я не вижу причин НЕ…
minimal vscode: убираем вкладки

https://www.youtube.com/watch?v=reT_wnDSaX4

Вкладки любят делать вид, что они очень полезны. Однако, такое впечатление обманчиво. Навигация по ним будет съедать у вас кучу времени. Взамен – есть способы лучше.

Что будет в видео?

- Как убрать вкладки?
- Как сделать заголовок вкладки читаемым?
- Что использовать вместо вкладок?
- Какие способы навигации удобнее вкладок?

Пельмени

Пельмени? Пельмени!

А еще в середине видео я решил попиарить свои любимые пельмени из родного Новосибирска. А мы там знаем толк в пельменях. Если вы не сидите в нашем чате, то вы пропустили все мемы про пельмени, и откуда вообще такая тема пошла :)

Сделал для вас набор рецептов для их приготовления от самого простого уровня до довольно замороченного: github.com/sobolevn/the-best-python-course/tree/main/minimal_vscode/dumplings

Рецепты написаны на языке Cooklang: https://cooklang.org
Специальный язык для разметки рецептов + среда для рендеринга рецептов в терминале и в виде сайтика.
Очень прикольная штука, выглядит вот так:


Положите пельмени в воду, варите пока не всплывут все пельмени и еще ~{7%min} после.
Главное – не переварить, блин!

При подаче смешайте @кетчуп и @майонез в качестве соуса.


Теперь у меня на гитхабе есть репозиторий, в котором в один момент времени есть:
- вызов syscall'ов на asm из питона
- рецепты пельменей с кетчунезом

Кстати про Новосибирск

Тут ребята организуют первый Python митап в Новосибирске: https://xn--r1a.website/python_in_nsk/698
Если вы живете где-то рядом, то присоединяйтесь: @python_in_nsk

Обсуждение: а как вы любите готовить ваши пельмени? 🥟

| Поддержать | YouTube | GitHub | Чат |
7770🔥36👍10😁8💩7🤡7
`__typing_subst__` – магический метод в Python, про который вы не слышали

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

А у нас есть только старый добрый питон и его объекты. Да, в питоне – действительно всё объект. Даже типизация. Оттого, любой код, который вы пишите в аннотациях – должен корректно работать в рантайме. Ведь у нас есть потребители такого, например: pydantic.

Скажем, у нас есть TypeAliasType объект с одной типовой переменной. Мы хотим её явно указать:


type StrDict[_V] = dict[str, _V]

numbers: StrDict[int] = {'one': 1}


Тут все довольно просто в рантайме: StrDict[int] вызовет __getitem__ вот тут. Кстати, там Cшный код, конечно же. И нам просто вернется нужный GenericAlias объект с нужными __args__:


>>> type StrDict[_V] = dict[str, _V]
>>> StrDict[int], type(StrDict[int]), StrDict[int].__args__
(StrDict[int], <class 'types.GenericAlias'>, (<class 'int'>,))


Мы видим, что замена _V на int работает! Пока что 🌚

А как физически происходит замена переменной?

Начнем с того, что в Python есть 3 TypeVar-like объекта: TypeVar, TypeVarTuple, ParamSpec. У каждого из них есть свои правила, как можно их заменять (в некоторых контекстах):
- TypeVar можно заменять на одно другое типовое значение
- TypeVarTuple можно заменять на любое количество типовых значений
- ParamSpec можно заменять на Concatenate, ... и список типов

Пример ошибки замены, исходник:


>>> from collections.abc import Callable
>>> from typing import ParamSpec, TypeVar
>>> P = ParamSpec('P')
>>> R = TypeVar('R')

>>> Callable[P, R][0, int]
Traceback (most recent call last):
TypeError: Expected a list of types, an ellipsis, ParamSpec, or Concatenate. Got <class 'int'>


Пытаемся заменить P на 0, что не является корректной заменой.
Но как фактически проверить, что замена корректная? И вот тут входит в дело __typing_subst__.

Он определен у всех типов TypeVar-like. Мы посмотрим на ParamSpec. Все, конечно же, написано на дикой смеси C и Python. И Cшная реализация ParamSpec.__typing_subst__ вызывает typing._paramspec_subst. Почему так? В 3.12 все переписали на C в спешке. Но некоторые части были слишком сложны, их оставили на питоне.

Аналогично:


>>> P.__typing_subst__([])
()
>>> P.__typing_subst__([int, str])
(<class 'int'>, <class 'str'>)
>>> P.__typing_subst__(...)
Ellipsis
>>> P.__typing_subst__(0)
Traceback (most recent call last):
TypeError: Expected a list of types, an ellipsis, ParamSpec, or Concatenate. Got 0


Подготовка к замене

Но, все еще чуть-чуть сложнее. Потому что перед тем как что-то заменить, нам нужно подготовиться к замене.
Есть второй магический метод, исходники: __typing_prepare_subst__. Он нужен, чтобы собрать аргументы для замены. Потому что у нас, например, могут быть неявные аргументы с default. Проверим на TypeVarTuple:


>>> class Custom[T1, *Ts=(int, int)]: ...
...
>>> Custom[str]
__main__.Custom[str, [int, int]]
>>> Custom[str, str]
__main__.Custom[str, str]


Ну или напрямую:


>>> Custom.__type_params__[1].__typing_prepare_subst__(*Custom.__type_params__[1], ())
([(<class 'int'>, <class 'int'>)],)

>>> Custom.__type_params__[1].__typing_prepare_subst__(*Custom.__type_params__[1], (str,))
((<class 'str'>,),)


Здесь в первом случае [int, int] нам как раз добавили в __args__ через __typing_prepare_subst__ вот тут.

Вот такая машинерия выполняется каждый раз, когда нам нужен Generic с параметрами. Потому с 3.14 все аннотации будут ленивыми по-умолчанию. А __annotate__ будет выполняться только тогда, когда аннотации будут запрашивать реально для рантайма.

Обсуждение: задумывались ли вы о работе аннотаций типов в рантайме? Сталкивались ли с проблемами в данной сфере? Тормозило?

| Поддержать | YouTube | GitHub | Чат |
6🤯5218🔥14👍5💩2👏1🤔1🕊1
Находки в опенсорсе: EasyP – тулбокс для ProtoBuf файлов

https://www.youtube.com/watch?v=XI-dNpM77iM

easyp – пакетный менеджер, билд-система и линтер для .proto файлов.
Хоть easyp и написан на #go 😱, одна из его фишек в том – что вы можете использовать любые плагины для генерации финального кода: он может быть хоть на #python, хоть на #rust.

Если много используете ProtoBuf – обязательно для ознакомления!

Как оно работает?


# Секция для правил линтера:
lint:
use:
- DEFAULT

# Секция с зависимостями:
deps:
- github.com/googleapis/googleapis
- github.com/grpc-ecosystem/grpc-gateway@v2.20.0

# Секция для правил сборки и генерации итоговых файлов:
generate:
plugins:
- name: go
out: .
opts:
paths: source_relative
- name: go-grpc
out: .
opts:
paths: source_relative
require_unimplemented_servers: false


Прощайте огромные Makefile с кучей скриптов для сборки.

Что будет в видео?

В видео:
- спросим зачем ребята его сделали
- узнаем как оно работает
- покажем, откуда можно устанавливать зависимости
- потыкаем разные юзкейсы
- поговорим про безопасность решения
- обсудим планы на следующие релизы
- расскажем как находить ломающие изменения в вашей ProtoBuf спецификации

А еще в видео кот на гитаре играет!

Репозиторий: https://github.com/easyp-tech/easyp
Документация: https://easyp.tech
Чатик сообщества: @easyptech

Поставьте пацанам звездочек, если проект понравился!

Обсуждение: Какие инструменты для ProtoBuf вы используете? Какие есть пролемы? Что можно было бы добавить в качестве новой фичи в easyp?

| Поддержать | YouTube | GitHub | Чат |
2228👍22🔥11🤯3
Набор новых интересных PEPов и обсуждений для 3.15+

Сегодня будет пост для тех, кто любит заглядывать в будущее.
Поговорим про то, что только-только начинают делать в питончике.

JIT и FT

https://github.com/python/cpython/issues/139038

Описывает планы на 3.15 и 3.16 по развитию JIT.
Самое важное планируют:
- Сделать JIT на 5-10% быстрее для всех случаев, до 50% скорости для краевых случаев
- Трассирующий JIT: https://github.com/python/cpython/issues/139109
- Поддежка Free-Threading режима: https://github.com/python/cpython/issues/133171
- К 3.16 планируют найти еще 2х меинтейнеров, потому что сейчас очень мало людей работают над джитом. Если всегда хотели - присоединяйтесь!

https://discuss.python.org/t/pre-pep-safe-parallel-python/103636

Обсуждение по будущему FT и subinterpreters как практических концепций.
Марк Шеннон предлагает сделать из Python Erlang 🌚

Каждому объекту предлагают добавить:
- Метод __freeze__() в большинство классов, чтобы делать объект иммутабельным (чтобы можно его было шарить между потоками и интерпретаторами)
- Метод __protect__(self: Self, obj: T) -> T, чтобы помечать объекты как "защищенные". Их можно менять, но с мьютексом
- И сам __mutex__, чтобы работать с защищенными объектами

https://discuss.python.org/t/add-virtual-threads-to-python/91403

Еще одно предложение от Марка – virtual threads в Python!
Кажется, что не только мне не нравится asyncio.

Обсуждение на очень раннем шаге, можно принять участие :)

PEPs

https://peps.python.org/pep-0798 позволит нам писать вот такой код:


list_of_lists = [[1, 2], [3, 4]]
flat_list = [*l for l in list_of_lists]


Если ПЕП примут, то можно будет делать unpacking прямо в comprehension. Не надо будет делать цикл или городить всякое сложное внутри. Крутое предложение, думаю, что его примут.

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

Кратко:
- Добавляет пакет profiling в CPython
- Чистый питоновский profile теперь deprecated
- В 3.15 добавили profiling.sampling
- cProfile теперь будет доступен еще и как profile.tracing

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

Добавляет такую возможность в TypedDict:


class Movie(TypedDict, extra_items=str):
name: str
rating: float
year: int


Что значит, что три ключа имеют явный тип, любые другие ключи имеют fallback тип str. Что удобно, если у нас гигантский json с кучей похожих полей, например.

И конечно можно будет указать такое:


class Movie(TypedDict, closed=True):
name: str
rating: float
year: int


Что будет значить, что никаких других ключей в словаре быть не может. Джва года ждал такую фичу!

https://peps.python.org/pep-0791 предлагает добавить новый модуль в Python: intmath

Решает старые проблемы модуля math. Если интересуетесь математикой в питоне – ПЕП для вас.

Обсуждение: как вам такой формат со ссылками? Что вы больше всего ждете из списка выше? Какие фичи вас бесят?

| Поддержать | YouTube | GitHub | Чат |
16👍196🔥6819🤔3👏2🤯2
Находки в опенсорсе
Большая бесплатная Python конференция в Нижнем Новгороде! У меня хорошая новость. Делаем бесплатную конфу по питону, пригласили топовых специалистов: core-разработчиков, контрибьюторов, организаторов разных комьюнити движух, специалистов из индустрии. И все…
Записи с нашей бесплатной конфы в Нижнем подъехали!

Во-первых, хочу еще раз повторить слова благодарности всем: организаторам и волонтерам, спикерам, участникам. Отдельно хочу отметить тех, кто поддержал конфу анонсами. Приехало и пришло очень много людей: 1100+ регистраций, почти 600 человек на площадке. Вы все крутые!

Во-вторых, в программе случились две замены. Ждем ребят, кто не смог приехать, на будущих мероприятиях.

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

Конкуренция за звание "лучшего" доклада – высочайшая. Выбирать будем не по каким-то там голосованиям, которые ни на что не влияют, а по просмотрам на ютюбе. Поддержите спикеров и меня просмотрами :)

Выкладываю записи сразу, а не через полгода.

Доклады в порядке выступлений:
- Чего вы не знали о строках в Python? Василий Рябов
- ИИ-агенты в каждый дом, Алексей Порядин @sw1logs
- Генератор байткода и байткод генератора, Михаил Ефимов
- Внутреннее устройство сборки мусора в CPython 3.14+, Сергей Мирянов
- Проектирование — это когда чувствуешь, а не какие-то там циферки, Николай Хитров @nkhitrov_blog
- Дотянуться до кремния. HighLoad Python: SIMD, GPU – Пётр Андреев @py_up
- Continuous profiling, Давид Джалаев @dzhalaevd_blog
- Vim — это метаредактирование, Илья Ильиных @kydavoiti

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

Наша традиционная вечеринка собрала полный бар людей, было очень весело. Отлично посидели, погуляли, поболтали. Лучшее сообщество!

При поддержке:
- https://it52.info
- https://itgorky.ru

Обсуждение: Кто был? Как вам конфа? Как вам Нижний Новгород?
Если понравилось: напишите приятное организаторам и спикерам. Если не понравилось – пишите вашу критику. Будем делать лучше.

| Поддержать | YouTube | GitHub | Чат |
24🔥116👍2826👏1
Находки в опенсорсе pinned «Записи с нашей бесплатной конфы в Нижнем подъехали! Во-первых, хочу еще раз повторить слова благодарности всем: организаторам и волонтерам, спикерам, участникам. Отдельно хочу отметить тех, кто поддержал конфу анонсами. Приехало и пришло очень много людей:…»
Минусы Litestar

Внезапно вспомнил, что я меинтейнер фреймворка Litestar.
Для тех, кто пропустил:

> Litestar не является микро-фреймворком. В отличие от таких фреймворков, как FastAPI, Starlette или Flask,
> Litestar изначально включает множество функций, необходимых для типичного современного веб-приложения,
> таких как интеграция с ORM, клиентские и серверные сессии, кэширование, поддержка OpenTelemetry и многое другое.


from dataclasses import dataclass
from litestar import Litestar, post

@dataclass
class User:
name: str

@post(path="/")
async def index(data: User) -> User:
return data

app = Litestar(route_handlers=[index])


И он классный:
- Быстрый
- Работает с Pydantic, msgspec и даже базовые dataclasses в качестве моделей
- Предоставляет базовые примитивы для работы с логикой: DTOs, Repository, Service (часть из них в advanced_sqlalchemy, очень удобно для крудов)
- Умеет из коробки в аутентификацию, метрики, DI, CORS, CSRF, кеширование, логирование, мониторинг, вебсокеты, htmx, сессии, загрузку файлов, разные ORMки и много всего еще
- Можно делать не только API, но и нормальные шаблончики
- Он с нами уже несколько лет, он работает
- А еще его делает большая команда, а не один человек

Кароче, просто лучший фреймворк (кроме Django, конечно).

Но! Сегодня речь пройдет про минусы. Которые скоро пофиксят в v3 (или которые все еще будут с нами)

Минусы

1. Самое главное: DI на именах. Да. Вот так:


class UserController(Controller):
path = "/user"
dependencies = {"user": Provide(retrieve_db_user)}

@patch(path="/{user_id:uuid}") # <- тут тоже можно указывать `dependencies`
async def get_user(self, user: User) -> User: ...


Что очень плохо. Тип user, который мы указываем в dependencies и в параметрах может не совпасть. Есть некоторая валидация для такого в рантайме, но все равно очень рисково.

Планы? Я предложил использовать dishka в качестве дефолтного DI, а старый задеприкейтить.

Высказать свое обоснованное мнение можно тут (или просто лайкнуть пост): https://github.com/orgs/litestar-org/discussions/4377

Хочу верить, что мы сможем поправить данную проблему в v3, ваши голоса – могут помочь :)

2. DI в middleware. А точнее отсутствие DI в middleware. Пока что приходится прокидывать зависимости через app.state, что очень криво. Данная проблема признана ошибкой дизайна и будет исправлено в v3, ура!

3. Своя схема для OpenAPI. Litestar переписал дефолтную схему pydantic, что позволило использовать более строгую схему, но переодически новые типы отваливаются. Например, pydantic.Json не обработан, имеет кривую схему. Сейчас мы обсуждаем стоит ли откатиться до дефолтной схемы. Стоит ли?

4. PydanticPlugin игнорирует ConfigDict, который объявлен в самой моделе, в v3 будет пофикшено. Сейчас параметры вроде by_alias и round_trip надо передавать в плагин. Что свело меня с ума, искал ошибку несколько часов

5. CLI местами разваливается, очень много багов и плохая читаемость

6. Очень сырая документация. Очень плохая навигация и структура, очень мало примеров, мало людей ее читало, мало людей находило проблемы, мало людей присылало PRы. Тут нужна ваша помощь очень сильно!

Итог

Отличный фреймворк, у которого есть некоторое количество детских проблем и ошибок проектирования. Но что отличает? Про них говорят, их исправляют.
Полный роадмап для версии v3: https://github.com/litestar-org/litestar/issues/4009

Обсуждение: Как вам Litestar? Какие минусы я забыл? Каких фичей не хватает? Что показалось сложным? Буду рад обратной связи :)
11🔥102👍3821👎4🤯4👏1🤔1👌1
PEP 810: Explicit lazy imports

На обсуждение вышел новый PEP, который предлагает добавить в Python 3.15 новый вид импортов.

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


lazy import json
lazy from json import dumps


Как будет работать?

Импорты не будут подгружаться до момента первого обращения к объекту.


import sys

lazy import json

print('json' in sys.modules) # Модуля еще нет

# Загрузка начинается вот тут:
result = json.dumps({"hello": "world"})

print('json' in sys.modules) # Теперь он загружен


Зачем?

- Быстрее загружать модули
- Позволит убрать много импортов из функций / методов
- Позволит убрать if TYPE_CHECKING: import some_module, было множество предложений по добавлению import type конструкции, пример: https://discuss.python.org/t/type-only-imports/96755
- Позволит решать циклические импорты
- Убирает необходимость в LazyLoader и страшных вещей вроде https://scientific-python.org/specs/spec-0001

Детали реализации

Планируется добавить:
- Функцию __lazy_import__ (аналог __import__ для импорта )
- Специальный атрибут на уровне модуля __lazy_modules__, где будут храниться ленивые импорты текущего модуля
- types.LazyImportType как тип нового "ленивого" модуля (аналог `types.ModuleType`)
- sys.lazy_modules для списка ленивых модулей глобально
- sys.set_lazy_imports_filter для глобальных настроек импортов, что? 🤯
- Байткод IMPORT_NAME получит флаг, является ли импорт ленивым
- Ошибки в именах модулей тоже будут ленивыми https://peps.python.org/pep-0810/#reification

Из забавного: import * не будет доступен в lazy режиме.


# SyntaxError: lazy from ... import * is not allowed
lazy from json import *


Реализация: https://github.com/LazyImportsCabal/cpython/tree/lazy

Обсуждение: как вам?

Бонус: меня тут в комментах спрашивают, куда я пропал. Я пропал в опенсорсе, пилю django-modern-rest. Простую и удобную библиотеку для REST API в Django. Пока на стадии pre-alpha, но уже скоро будет первый релиз. Можно уже ставить , чтобы потом всем говорить, что первыми узнали про новую модную штуку!

https://github.com/wemake-services/django-modern-rest

| Поддержать | YouTube | GitHub | Чат |
59🔥162👍32👎20🤮8💩8🤔7🤯65👏4😱2
Зачем нужен новый REST API для Django?

Последний месяц я крайне увлечен созданием https://github.com/wemake-services/django-modern-rest
(Кстати, у нас уже >200 звезд и 26 контрибьюторов при 0 релизов)

Ключевой вопрос – зачем? Что будет нового?

Во-первых, я крайне сильно люблю Django. Основная причина – под него есть буквально любые библиотеки. Все то, что в FastAPI нужно героически писать руками – в джанге уже давно есть и работает.
Но, есть несколько основных причин, почему люди думают, что не любят джангу:
1. DRF, тут без лишних слов – он ужасен. Нет типизации, нет async, очень сложно работать с ним в сложных случаях
2. Многие считают, что джанга - сложная. Однако, она как FastAPI или Litestar может спокойно уместиться в один файл: https://django-modern-rest.readthedocs.io/en/latest/pages/micro-framework.html
3. Есть критика за архитектуру: тут нечего особо даже комментировать. На любом фреймворке можно писать хорошо, на любом можно писать плохо. Слой фреймворка очень тонкий
4. Медленный. А вот тут остановимся подробнее.

На скринах выше можно сравнить, что с django-modern-rest, без нескольких будущих оптимизаций (привет cython и rust!), голая джанга начинает выглядеть не так уж и медленнее FastAPI: бенчи.

Во-вторых, Django на длительный срок был в плену DRF. Который морально устарел еще в середине десятых.
Потом появилась django-ninja, которая хоть и намного лучше, но все равно не решает главную задачу: интеграция с существующими тулами. Конечно, если затащить FastAPI дизайн в чужой мир, то ничего не будет нормально работать 🌚️

Вот такие проблемы мы решаем.

Одной строкой:
- Супер строгая OpenAPI схема и валидация при разработке, что мы ее соблюдаем
- Полная типизация всего
- Нормальный способ создания АПИ, без god-functions a-la FastAPI
- async без sync_to_async
- Быстро: msgspec для парсинга json (самый быстрый способ в питоне), практически 0 работы в рантайме (все делаем при импорте), оптимизации роутера (быстрее дефолтного в 51 раз)
- Пидантик, msgspec, или любой другой способ выражать модели. Хоть adaptix
- Полная поддержка всего существующего в Django. От декораторов до миддлварь (с полной валидацией и OpenAPI схемой!)
- OpenAPI схема из коробки
- Удобное тестирование с polyfactory
- property-based тесты вашего АПИ одной командой благодаря schemathesis

Что еще будет:
- RSGI (да, на #rust скорее всего) под granian, в теории можем побить FastAPI после такого
- SSE с автоматической OpenAPI спекой и умной валидацией схемы
- JWT или любая другая аутентификация
- Какие-то части (скорее всего валидацию) мы компильнем cython, чтобы было еще быстрее

Modern? Modern!
Осталось дождаться. Релиз скоро!
И еще скоро будут несколько новых видео.

Мы регулярно постим задачки в @opensource_findings_python, так что можно нам помочь.
А если кто хочет мне закинуть на развитие опенсорса (за написание 32500 строк кода за 2 недели), то мой бусти открыт: https://boosty.to/sobolevn
Ну и звезды можно ставить, конечно же. Там посмотрите, какие люди нас уже советуют.

Большое спасибо Александру, Алексею, Роману, Максиму и всем остальным за неоценимую помощь. Пацаны, без вас никак! Лучшее сообщество!

Обсуждение: а чего бы вам хотелось в modern rest фреймворке? Чего сильно не хватает сейчас?
68👍149🔥5852💩6😁2