Хорошо разжёвано как asyncio взаимодействует с ядром ОС. Если epoll для вас что-то странное и незнакомое, то велкам. А про трюк с self-pipe я и сам не знал; элегантно получилось :)

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

Ключевой абзац:

На каждой итерации он [event loop] сначала решает, сколько времени ему можно спать в ожидании событий. Если в очереди `_ready` уже есть работа, таймаут равен нулю — цикл только заберёт накопившиеся I/O-события и сразу перейдёт к исполнению. Если очередь пуста, цикл смотрит на ближайший таймер. Если таймеров нет, он выбирает бесконечный таймаут и готов проснуться только от событий ввода-вывода или от self-pipe. Если таймеры есть, он вычисляет, через сколько должен сработать ближайший, и использует эту величину как `timeout` для ожидания в epoll: так ядро разбудит поток либо раньше по I/O-событию, либо не позже нужного момента по истечении таймаута.

И пруфы для статьи. Загляните, там не сложно :)

Ну и какой async/await без тасок и футур :) Так что продолжение - Как устроены задачи (Task) в asyncio.

Нерегулярная рубрика "посмотрите, что творится!". Как вы знаете, рынок найма http клиентов полностью сломан! Сегодня мы постараемся решить данную проблему.

zapros - modern and extensible python http client

Звезды ставить сюда: https://github.com/kap-sh/zapros
Документация: https://zapros.dev
Сообщество: @pythonzapros

Недавно мне написал Карен Петросян (кстати, заходите к нам в чат, где все события и происходят) – топ3 мейнтейнер библиотеки HTTPX по количеству коммитов, автор httpx-aiohttp и hishel. И говорит: я сделал новый крутой клиент для HTTP для питона. И я такой: офигеть! Дайте два!

В чем фишка?

А ситуация на рынке такова. requests морально устарел 10 лет назад. На фоне умирающего HTTPX, у которого не было релиза больше года, и автор которого не хочет релизить новые версии и даже заблокировал возможность создавать новые задачи, автор Zapros попытался написать аналог, способный не только заменить HTTPX, но и предложить кучу новых интересных фич.

from zapros import AsyncClient

async def main() -> None:
     async with AsyncClient() as client:
          response = await client.get("https://httpbin.org/get")

     print(response.status, response.json)

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

- HTTP/1, HTTP/2 и HTTP/3 - независимость от транспортного уровня позволяет использовать интерфейс Zapros поверх любых транспортных реализаций.
- Rust - поддерживает транспортную реализацию поверх Rust-библиотеки reqwest
- Работа в браузере (через Pyodide) - ещё раз, транспортный уровень `Zapros`-а полностью независим от самого клиента, и из коробки поддерживает работу в браузере, используя fetch API.

Идея независимости от транспортного уровня появилась у автора во время работы над проектом httpx-aiohttp, который был создан, чтобы «спасти» HTTPX от багнутой реализации транспортного уровня, подменяя его на aiohttp. В итоге проект вырос в полноценную библиотеку, используемую в SDK от OpenAI и Anthropic.

Zapros имеет всего лишь 3 зависимости: h11, pywhatwgurl и typing-extensions. Поддерживает Python 3.10 и выше.

Уделяя особое внимание расширяемости, Zapros был спроектирован с удобным механизмом расширения клиента с помощью миддлварей. Из коробки идут миддлвари для:

- Моков - позволяет мокать запросы без необходимости в сторонних библиотеках.
- Кеширования - позволяет кешировать запросы в памяти или на диске (работает поверх библиотеки `hishel`).
- Ретраев - позволяет автоматически повторять запросы при неудаче с помощью настраиваемой логики.
- Кук - автоматически управляет куками.
- Кассет - позволяет записывать и воспроизводить HTTP-взаимодействия, что полезно для тестирования и отладки (аналог vcr).
- Редиректов - автоматически обрабатывает HTTP-редиректы согласно стандарту HTTP (RFC 9111).

from zapros import CacheMiddleware, Client, RetryMiddleware

with (
    Client().wrap_with_middleware(
        lambda next: RetryMiddleware(next)  # wrap with the retry middleware
    ).wrap_with_middleware(
        lambda next: CacheMiddleware(next)  # wrap with the cache middleware
    ) as client
):
    # automatically retries failed requests and caches responses
    client.get("https://zapros.dev")

Zapros не принуждает использовать ни одну из данных миддлварей: сам класс клиента отвечает только за отправку HTTP-запросов, всё остальное — уже миддлвари, которые вы можете использовать по своему усмотрению. И хотя основные миддлвари написаны так, чтобы покрывать большинство случаев использования, вы можете использовать и свои кастомные решения.

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

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

друзья, победа

больше не будет fastapi

Вышел mypy 2.0

Changelog: https://github.com/python/mypy/blob/master/CHANGELOG.md#mypy-20

Что изменилось?

По-умолчанию --local-partial-types теперь всегда включен. Он нужен для корректной типизации типов в разных скоупах.

a = []  # Needs type annotation when using `local-partial-types`

def func() -> None:
    a.append(1)

Включили --strict-bytes по-умолчанию. Раньше тип bytes разрешал передавать memoryview и bytearray. Теперь с новым поведением bytes разрешает только bytes, все остальные типы нужно указывать отдельно.

Теперь можно переопределять переменные, даже разных типов с --allow-redefinition

def foo(cond: bool) -> None:
    if cond:
        for x in ["a", "b"]:
            # Type of "x" is "str" here
            ...
    else:
        for x in [1, 2]:
            # Type of "x" is "int" here
            ...

Данная фича раньше была под флагом --allow-redefinition-new, а теперь включена по-умолчанию.

Самое интересное

Добавили --num-workers, который позволяет ускорить mypy кратно на больших кодовых базах. Я буду запускать mypy прямо на кодовой базе mypy (без mypyc, без кеша, но с orjson и `sqlite_cache`):

» rm -rf .mypy_cache && time mypy --config-file mypy_self_check.ini -p mypy -p mypyc --num-workers=8
7.090 total

Против режима с одним воркером (как было до 2.0):

» rm -rf .mypy_cache && time mypy --config-file mypy_self_check.ini -p mypy -p mypyc 
25.335 total

А теперь еще убираем orjson и sqlite_cache:

» rm -rf .mypy_cache && time mypy --config-file mypy_self_check.ini -p mypy -p mypyc 
28.108 total

Вот такой прирост производительности. Версия с mypyc (то есть та, которую мы скачиваем из pip) будет еще быстрее.

Очень радостно, что mypy становится быстрее. Дальнейшее развитие mypyc приведет к еще большему перфу. И не только для mypy.

Обсуждение: Как быстро вы обновляете mypy на своих проектах? Насколько сурово настраиваете? Будет ли профит от нескольких воркеров?

| Поддержать | YouTube | GitHub | Чат |

Вы, наверное, уже забыли, как около 3 месяцев назад я анонсировал свою либу по работе с конфигами. С тех пор она стала более зрелой и сильно изменилась:

- Я полностью переработал публичный интерфейс либы и она стала проще, без импортов лишних сущностей и понятнее, чем было.

- все примеры из доки прогоняются каждый раз при тестировании. А значит они всегда актуальны

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

- было переработано маскирование - теперь настройки хранятся в одном конфиге, который можно менять глобально.

- была полностью переработана валидация. Теперь кастомные Le/Ge/MinLength пересобраны в объект V, с которым можно V >=, V.len() > 3 и тп.

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

- добавился cli для быстрой проверки и cli как источник на примере argparse.

- добавился VaultSource

- добавилось TTL кеширование, синхронизированное для всех источников (содержимое одного и того же окна становится невалидным в один и тот же момент)

Да и честно говоря очень много всяких переработок.

Уже пройден немалый путь, однако либу ещё ждут некоторые крупные изменения, помимо новых источников. Пока все крупные изменения не затащу - мажорный релиз 1.0 делать не планирую, но это не значит, что она нестабильна - написано ~2к тестов, покрытие ~95%.

Так что, кто думал - пора или не пора - думаю пора.
Гитхаб. Дока. Сообщество reagento.

Относительно скоро планирую выпустить статью на хабре, где расскажу побольше про либу и как/когда ей пользоваться

Coming soon, stay tuned!

Да блин 🤬🤬🤬 ну нафиг этот ваш ИТ! Пойду картошку сажать.
https://habr.com/ru/articles/1042160/

Чудо свершилось!

Мы его сразу ждали тут - https://t.me/tech_b0lt_Genona/6559

Роскомнадзор не ограничивал доступ к Python
https://www.kommersant.ru/doc/8709086

pypi.org теперь работает.

Но OWASP по прежнему соболезнуем
https://t.me/tech_b0lt_Genona/6560

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

https://discuss.python.org/t/an-announcement-from-the-steering-council-regarding-the-jit-project/107638
Коротко: Если ребята работающие над джитом не предоставят предельно ясный PEP с дальнейшими планами проекта, JIT будет удален из языка.
ссылку украл у Никиты Соболева

⚡️ Закрыл основные задачи по dature и переключаюсь на помощь adaptix

Основная гора работы над dature позади. Из последнего, что успел туда затащить, — наконец-то допилил фичи when и ref. Теперь появилась полноценная возможность ссылаться из одного источника конфигурации (source) на другой.

Если на пальцах: теперь можно прямо в конфиге сказать: «если текущий environment равен PRODUCTION, то возьми креды из HashiCorp Vault по ссылке, а если LOCAL — подтяни из обычного .env». Архитектурно пришлось посидеть, но теперь всё работает стабильно. Проект уходит в режим точечной поддержки.

What's next?

Официально собираюсь вкатиться в помощь парням в adaptix, чтобы общими усилиями дотащить его до стабильного мажорного релиза (v3.0).
Планирую подключиться к @pvlzhr и помочь с горящими задачами: написанием тестов для генерации JSON-схем и переносом части компонентов из _internal в публичную часть (так как dature от этого зависит). Почему JSON-схема так важна - я, честно говоря, хз, но @pvlzhr она очень нужна, так что будем делать. Работа низкоуровневая и занудная, но критически важная для стабилизации API перед релизом.

Дальнейшие планы:

Сам я сейчас работаю в Т-Банке. И как только мы выпустим стабильную тройку adaptix и сделаем мажорный релиз dature, я собираюсь топить за этот инструмент на полную мощность. Буду выступать в роли евангелиста: сначала подарю библиотеку своей команде, потом приду в смежные команды, а затем планирую раскатать этот опыт на всю нашу внутреннюю Python-профессию. Инструмент объективно получается быстрее и гибче аналогов, так что пора выводить его в массы.

Кто уже ковырял беты adaptix или успел пощупать dature — как вам? Пишите в комменты

Если вдруг кто-то из вас сидит на арче - у меня для вас плохая новость. Очень много пакетов было инфицировано.

Чекнуть можно так

curl -s https://cscs.pastes.sh/raw/aurvulntest20260611.sh | bash

(На самом деле там просто перечисление пакетов и простенький цикл в конце, см картинку в посте)

https://x.com/i/status/2065480567534080397

Казалось, Max пробил дно, но снизу снова постучали. На этот раз российский менеджер пакетов RuStore. Наглость не знает границ 😱 Сливается вообще всё:
- список установленных приложений
- статистика их использования
- координаты устройства
- прочая телеметрия
Даже за каталогом с фотографиями следит... И в добавок ещё он может по-тихому установить вам Max. Даже не информируя. Не нуачо? Пригодится!

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

🧠 Студенты разучились читать. И это уже наша проблема.

Препод риторики дал студентам 20-страничную статью. Ту же, что давал 5 лет назад. Не дочитал никто. Девочка честно сказала: «слишком длинно, я теряла нить».

Это не «вот молодёжь пошла». Это цифры:

* NAEP-2024: чтение у американских 12-классников - и это худший результат с 1992 года, когда тест вообще начали проводить.
* 32% выпускников школ не могут сделать вывод из явно написанного текста. Больше половины из них всё равно идут в колледж.
* Препринт MIT Your Brain on ChatGPT : у тех, кто писал эссе с LLM, нейронная связность ниже до 55%. 83% не смогли процитировать ни строчки из текста, который написали сами пять минут назад. Авторы ввели термин - «когнитивный долг». Когда ИИ убирают, мозг обратно не включается.
* Бонусом: само наличие смартфона рядом, даже выключенного, экраном вниз, режет рабочую память. Это не эзотерика, это fMRI.

Смартфоны. Школа, где вместо длинных текстов натаскивают на короткие отрывки под тесты. LLM, которые дописывают мысль раньше, чем ты успел её подумать.

А теперь зачем это нам в сфере IT.

Длинный контекст - и есть наша работа. Чужой код, RFC, ТЗ, постмортемы, архитектурные доки, security-репорты, ту же доку по adaptix прочитать. Если человек физически не вывозит 20 страниц, он не вывезет ни большой PR, ни legacy, ни проверку того, что нагаллюцинировал Claude.

И тут грустная мысль. Vibe coding - это не будущее, это симптом. Поколение, которое учится писать код только с Cursor/Copilot, не нарабатывает паттернов самостоятельного решения задач. Без вендора ИИ такой инженер не кодит. А вендор иногда сорсмапы в npm заливает (привет Anthropic), иногда нёрфит модель без предупреждения, и всегда дорожает.

NYT недавно сформулировал жёстко: мышление становится предметом роскоши. Звучит пафосно, но по ИТ бьёт прямо. Через 5 лет «умею прочитать и понять 20 страниц» из базового навыка превратится в конкурентное преимущество. И вилка между инженером и промпт-оператором будет шире, чем сегодня между джуном и сеньором.

Что с этим делать.

В команде - иметь культуру дизайн-доков и RFC. Amazon-style 6-pager раздражает первые два раза, потом понимаешь, зачем он.

В найме - не только литкод, а «прочитай вот этот кусок чужого кода и расскажи, что он делает». Это, внезапно, и есть проверка рабочей памяти.

Лично себе - телефон из комнаты, час длинного текста в день. Звучит как херня из ТЕДа, но по ощущениям работает как поход в зал. Первые две недели тяжело, потом мозг возвращается. И LLM подключать после того, как сам понял задачу. Не вместо.

ИИ не отменяет умение думать. Он поднимает цену тех, кто ещё умеет.

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

В общем, в интернетах начинают разбираться, что на практике означают гигантские контекстные окна (например, 200k, миллион токенов или даже больше) в моделхя для написания кода, и приходят к выводу, что в таких контекстных окнах больше маркетинга, чем пользы.

Условно контекстное окно можно разделить на две зоны - «умную» и «глупую». Умная зона - это там, где модель работает чётко и уверенно, а глупая - где внимание ослабевает и начинаются разные неприятные казусы, вроде проигнорированного замечания пользователя, написанного совсем недавно или проигнорированного правила.

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

С этой проблемой пытаются бороться разными "костыльными" способами. Например, с помощью функции сжатия контекста. Но тут надо понимать, что эффективность такого сжатия может быть не на высоте, потому что агент уже какое-то время проболтался в «глупой» зоне, качество его работы успело снизиться, и поэтому до автоматического сжатия контекста лучше вообще не доводить.

https://garrit.xyz/posts/2026-05-06-dont-trust-large-context-windows

@g33ks

Комитет IETF наконец-то утвердил стандарт RFC 10008, который узаконил метод QUERY.

Спецификацию мурыжили в черновиках около пяти лет (с 2020–2021 годов), но теперь мучения окончены. По сути, мы получили тот самый легитимный «GET с телом запроса», которого так не хватало для сложной фильтрации.

В чем была боль?

Раньше для тяжелого поиска с кучей параметров приходилось выбирать из двух зол:
- GET с гигантским URL. Длинные строки запроса падали по таймауту, забивали логи конфиденциальными данными и обрезались старыми прокси-серверами. Попытки засунуть payload в тело GET приводили к тому, что сетевое оборудование (Nginx, AWS ALB) этот боди просто выкидывало.

- Семантический костыль в виде POST. Сюда можно было зашить любой JSON, но POST по стандарту не является безопасным и идемпотентным. Как результат — CDN и браузеры отказывались кэшировать такие ответы, заставляя сервер вычислять один и тот же поиск по новой.

Как решает проблему QUERY?

- Метод QUERY объединяет безопасность GET и гибкость POST - идемпотентность и безопасность. Метод строго предназначен для чтения и не имеет права изменять состояние ресурса на сервере.

- Полноценный Payload. В тело запроса можно легально упаковывать сложные структуры — JSON, GraphQL или SQL-подобный синтаксис. Сетевые шлюзы больше не будут их резать.

- Смарт-кэширование. Стандарт обязывает кэширующие прокси и CDN учитывать содержимое тела запроса при формировании ключа кэша (Cache Key). Два одинаковых запроса с идентичным JSON-телом теперь корректно кэшируются.

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

GitHub выкатили первую правку по борьбе со слопом - теперь можно ограничить количество открытых PR'ов от пользователь без write прав на репу

https://github.blog/changelog/2026-06-17-limit-open-pull-requests-for-users-without-write-access/

Фича прикольная, т.к. у меня теперь не будет 5ти открытых PR'ов от одного бота. Будет 1-2. Не думаю, что это сильно решит проблему - ведь после первого PR'а будет второй, потом третий... Да и ботов на GH тоже не один. Но это доказывает, что GH понимает проблему и пытается ее как-то решить - посмотрим, что будет дальше

ВБ уже продает курсы по вайбкодингу 🌚
https://tech.wildberries.ru/vibe-coding

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

https://discuss.python.org/t/2026-python-core-dev-sprint-at-openai/106928/13
Полу-драмма происходит на наших глазах.
Каждый год осенью происходит Core sprint для участников команды CPython. В этом году его отважились хостить OpenAI. 57 участников подали заявку, а мест то оказалось всего 40. OpenAI не могут пожертвовать денег на дополнительное помещение на недостающие 17 лиц.

Поражает.