un article de @mkennedy indiquant que depuis Python 3.12, asyncio.create_task() ne garde qu'une référence faible vers la tâche lancée dans la boucle d'évènement, et que celle-ci peut se faire garbage-collecter avant (la fin de) son exécution : https://mkennedy.codes/posts/fire-and-forget-or-never-with-python-s-asyncio/

La solution ? Garder une référence forte de la tâche (dans un set, par exemple) et ajouter un done_callback qui l'en retire pour la déréférencer afin que le garbage collector puisse faire son travail.

#Python #tutoriel #asyncio

Fire and forget (or never) with Python’s asyncio

Python's asyncio.create_task() can silently garbage collect fire-and-forget tasks in 3.12+. Learn the background_tasks set pattern to fix it.

Michael Kennedy's Thoughts on Technology

Асинхронность в Python для senior interview: от asyncio до выбора правильной реализации под задачу

Асинхронность в Python — одна из тех тем где на собеседовании начинают плыть. Почему await не делает код параллельным? Как на самом деле работает event loop? Когда asyncio — правильный выбор, а когда лучше использовать потоки или процессы? В этой статье разберём асинхронность с прицелом на senior Python интервью: не с точки зрения API, а с точки зрения того, как всё устроено под капотом и как об этом правильно рассуждать . Материал рассчитан на тех, кто хочет не просто отвечать по документации, а уверенно объяснять поведение системы и принимать инженерные решения. Подробнее

https://habr.com/ru/articles/1011544/

#Python #asyncio #асинхронность #nonblocking_io #cooperative_multitasking #backend #event_loop

Асинхронность в Python для senior interview: от asyncio до выбора правильной реализации под задачу

Каждый Python-разработчик знает базовую формулу: asyncio нужен для I/O, потоки ну тоже иногда, процессы — для CPU-bound. На собеседовании такого ответа хватает ровно до первого уточняющего вопроса. А...

Хабр

github-monitor is now forgewatch!

I rebranded my PR monitoring daemon. The old name locked it to a single platform, but the vision has always been broader than that. "forgewatch" better reflects what the app is really about: watching over your code forge, wherever it lives.

Why the rename? Two reasons:

1. It's more general. The architecture doesn't depend on GitHub specifically, and I want to grow it to support GitLab, Gitea, and other forges over time.
2. It's more descriptive. "forgewatch" tells you exactly what it does -- it watches your forge for pull requests and keeps you notified via D-Bus and desktop notifications on Linux.

The daemon is async Python, runs as a systemd user service, and comes with an optional system tray indicator. Give it a look if you're a Linux dev who juggles PRs across repos.

https://github.com/dvoraj75/forgewatch
https://pypi.org/project/forgewatch/

#forgewatch #opensource #python #linux #devtools #foss #github #gitlab #gitea #asyncio #dbus #systemd

GitHub - dvoraj75/forgewatch: Async daemon with system tray indicator and CLI tools for monitoring GitHub pull requests with desktop notifications and systemd integration (Linux)

Async daemon with system tray indicator and CLI tools for monitoring GitHub pull requests with desktop notifications and systemd integration (Linux) - dvoraj75/forgewatch

GitHub

Novo artigo no blog: asyncio na prática.

async/await não torna seu código automaticamente mais rápido. Se a tarefa é CPU-bound, você só adiciona complexidade sem ganho nenhum. A diferença aparece mesmo no I/O — e é dramática.

O artigo mostra os dois casos com exemplos reais, explica o event loop e quando vale (ou não) usar concorrência.

🔗 https://www.riverfount.dev.br/posts/asyncio_na_pratica/

Você já teve bug causado por uso errado de asyncio em produção?

#python #asyncio #concorrência #performance

asyncio na prática: quando concorrência resolve e quando atrapalha

Se você chegou até aqui provavelmente já passou pelo profiling e encontrou um gargalo. A tentação imediata é jogar async/await em cima do problema e torcer para que o tempo de execução caia. Na maioria das vezes, não cai. Às vezes, piora. Este artigo começa mostrando exatamente esse cenário — código assíncrono que não resolve nada — e explica por quê. Depois mostra um caso onde asyncio faz diferença real, e só então desce para o mecanismo que explica os dois resultados.

Blog do Riverfount
The article promises an #exposé on Python's #asyncio and shared state woes but instead serves up a lukewarm brew of tech buzzwords and self-promotion. 😴💤 Spoiler alert: their "observable pattern that finally works" is as elusive as #Bigfoot. 🦄
https://www.inngest.com/blog/no-lost-updates-python-asyncio #Python #techbuzzwords #sharedstate #HackerNews #ngated
What Python's asyncio primitives get wrong about shared state - Inngest Blog

We tried Event, Condition, and Queue. Each one gets closer but still breaks under real concurrency. Here's the observable pattern that finally works.

What Python's asyncio primitives get wrong about shared state - Inngest Blog

We tried Event, Condition, and Queue. Each one gets closer but still breaks under real concurrency. Here's the observable pattern that finally works.

Как я устал дебажить MAX API, отреверсил их вебхуки и отучил Cursor галлюцинировать

Как я устал дебажить MAX API, отреверсил их вебхуки и отучил Cursor галлюцинировать Когда я писал своего первого более-менее серьезного бота под Max, случилась классика. Я и мой ИИ-ассистент (Cursor) пишем код, строго опираясь на официальную документацию Max API. Запускаю — падает. Сижу по 5-6 итераций, пытаюсь отдебажить базовый функционал, который под ту же Телегу пишется с закрытыми глазами. В какой-то момент меня это достало. Я понял, что проблема не во мне и не в галлюцинациях нейронки. Я просто включил логирование всех входящих POST-запросов и стал дампить реальные вебхуки, которые прилетают от серверов Max. Открыв логи, я понял, почему мы так долго буксовали: то, что написано в документации, и то, что прилетает по факту — это две большие разницы. А слепая привычка писать архитектуру под Telegram Bot API делает только хуже. Различия с официальной документацией Max API (Docs vs Реальность) Вскрываем реальные вебхуки Max API

https://habr.com/ru/articles/1005282/

#python #template #boilerplate #chatbot #aiohttp #asyncio #maxapi #maxmessenger #telegram #telegram_bots

Как я устал дебажить MAX API, отреверсил их вебхуки и отучил Cursor галлюцинировать

Когда я писал своего первого более-менее серьезного бота под Max, случилась классика. Я и мой ИИ-ассистент (Cursor) пишем код, строго опираясь на официальную документацию Max API. Запускаю — падает....

Хабр

Анатомия WebSocket: человечный разбор RFC 6455

Как правило, работа с веб-сокетами сводится к паре строк: connect() и send() . Удобные абстракции библиотек превратили этот протокол в магическую трубу, по которой летают данные в обе стороны. Но магия заканчивается ровно в тот момент, когда соединение молча отваливается с кодом 1006 , балансировщик рвет коннект, а в логах появляются странные ошибки фрагментации. В этой статье мы спустимся с небес высокоуровневых фреймворков на уровень байтов и битовых масок. Мы пройдем полный путь WebSocket-соединения, опираясь на RFC 6455: от генерации ключа на стороне клиента до обмена закрывающими фреймами. Попутно разберем весь необходимый понятийный аппарат: что такое фреймы, какими они бывают, зачем их маскируют и фрагментируют и т.д. Цель не в том, чтобы научиться пользоваться конкретной библиотекой, а в том, чтобы понять, как протокол работает изнутри независимо от языка и реализации. Для иллюстраций по тексту статьи даны сниппеты на Python. Погружаемся

https://habr.com/ru/articles/1004772/

#websocket #вебсокет #asyncio #сети #база

Анатомия WebSocket: человечный разбор RFC 6455

Чем мы займемся Как правило, работа с веб-сокетами сводится к паре строк: connect() и send() . Удобные абстракции библиотек превратили этот протокол в магическую трубу, по которой летают данные в обе...

Хабр

От WSGI к ASGI: как Python научился работать с асинхронным вебом

WSGI и ASGI — то, на чем стоит весь современный веб на Python. Это стандарты, которые описывают интерфейс между веб-сервером и приложением. Благодаря им сервер и фреймворк не образуют жесткую пару: любой WSGI-сервер запускает любое WSGI-приложение, любой ASGI-сервер любое ASGI-приложение. Uvicorn не знает ничего о FastAPI, FastAPI не знает ничего о Uvicorn, они знают только о том, что передать на вход и что ожидать на выходе. Разберем, как все это устроено. Погружаемся

https://habr.com/ru/articles/1003282/

#python #asgi #wsgi #вебсервер #asyncio #starlette #uvicorn

От WSGI к ASGI: как Python научился работать с асинхронным вебом

Введение WSGI и ASGI — то, на чем стоит весь современный веб на Python. Это стандарты, которые описывают интерфейс между веб-сервером и приложением. Благодаря им сервер и фреймворк не образуют жесткую...

Хабр