1. asyncio.timeout(0) назначает отмену на ближайшую итерацию цикла событий. Event создан без установленного флага, и никто не вызовет set(). Поэтому wait() приостанавливает текущую задачу.
2. Тайм-аут отменяет эту задачу. В точке await возникает asyncio.CancelledError. Внутренний except TimeoutError его не перехватывает, строка inside не печатается.
3. При выходе из async with менеджер timeout преобразует свою отмену в TimeoutError. Внешний обработчик печатает outside. Затем выполнение продолжается и печатает done.
Правильный вариант: outside | done. Вариант inside | done предполагает, что TimeoutError попадёт во внутренний обработчик ещё до преобразования отмены в это исключение. Обе метки одновременно тоже не печатаются. Только done потребовало бы завершения ожидания без тайм-аута, а событие никто не устанавливает.
Обработчик TimeoutError размещайте снаружи нужного timeout-контекста. Не поглощайте CancelledError внутри операции: механизм тайм-аута использует отмену. В этом примере нет задержки sleep и зависимости от скорости компьютера.
1. Job("Night Build") вызывает сгенерированный __init__, затем __post_init__. В первый раз slug становится "night-build". Следующая строка вручную заменяет его на "manual".
2. replace(old, name="Quick Fix") создаёт новый Job через __init__. Поле slug помечено init=False и из old не копируется.
3. У нового объекта снова вызывается __post_init__. Именно наш метод вычисляет slug из нового name и получает "quick-fix". Исходный объект не меняется. Вывод — manual quick-fix.
Вариант manual manual предполагал бы копирование slug. Вариант night-build quick-fix не учитывает ручное изменение old.slug. ValueError возник бы при попытке передать slug в changes, например dc.replace(old, slug="forced"), но здесь меняется допустимое поле name.
Для вычисляемых полей учитывайте повторный вызов __post_init__ при replace. Само init=False не задаёт формулу пересчёта. В этой задаче она явно написана в методе, а ручная правка вычисляемого поля не переносится в новый объект.
1. У экземпляра ReadyJob есть метод __await__. При его вызове создаётся корутина finish и возвращается её итератор. Так объект поддерживает протокол awaitable: его можно ожидать через await.
2. В Python 3.14
3. finish возвращает строку index-ready. Она становится результатом ожидания, затем результатом
Почему это важно
Если библиотека возвращает собственный awaitable, в Python 3.14 его можно передать напрямую в точку входа. Не нужно добавлять корутину-обёртку только ради типа аргумента. Но
Код проверен в CPython 3.14.4.
1. t-строка в Python 3.14 создаёт объект Template. Выражение limit вычисляется при создании шаблона, поэтому первая интерполяция хранит целое число 7.
2. Спецификация 04d сохраняется отдельно в format_spec. Она ещё не превращает значение в строку 0007. Поэтому первый print выводит 7 04d: исходное число и спецификацию через пробел.
3. Дальше код сам собирает результат. template.strings[0] содержит «limit=», а strings[1] — пустую строку после интерполяции. Между ними добавляется результат format(7, "04d"). Он равен строке 0007, так что второй print выводит limit=0007.
Почему это важно
Обработчик t-строки получает и значение с его типом, и указания по форматированию. Именно обработчик решает, применять ли format и как собирать результат. Здесь показан один подставляемый фрагмент, это не универсальный рендерер шаблонов. Для обычной готовой строки с таким форматированием достаточно f-строки.
Код проверен в CPython 3.14.4.
1. В Python 3.14 аннотации по умолчанию вычисляются отложенно. Поэтому функция dispatch объявляется, хотя имя Payload ещё не определено. Импорта future в этом примере нет.
2. get_annotations вызывается до объявления класса. Режим FORWARDREF позволяет вернуть объект ForwardRef для неизвестного имени вместо ошибки при попытке получить его значение. Здесь ref хранит ссылку на Payload. Первый print выводит ForwardRef Payload.
3. Затем выполняется объявление class Payload, и имя появляется в глобальном пространстве модуля. Вызов ref.evaluate() разрешает сохранённую ссылку с учётом этого пространства. Получается тот же объект класса, поэтому проверка is Payload выводит True.
Почему это важно
Реестр плагинов может прочитать аннотации до загрузки всех типов и разрешить недостающие ссылки позже. Важно выбрать подходящий момент: FORWARDREF не создаёт отсутствующий класс. Здесь проверено простое глобальное имя. Чтение и вычисление аннотаций может выполнять код, поэтому этот приём не делает чужие аннотации безопасными.
Код проверен в CPython 3.14.4.
1. У request_id задано значение по умолчанию — строка none. В текущем контексте переменную ещё не устанавливали, поэтому первый get возвращает именно эту строку. Она отличается от специального значения None.
2. Вызов set устанавливает req-7 и возвращает Token, который позволяет отменить это изменение. Начиная с Python 3.14 Token поддерживает контекстный менеджер. Поэтому выражение with request_id.set(...) корректно, а внутри блока get возвращает req-7.
3. При выходе из with токен восстанавливает состояние до set. Здесь явно установленного значения раньше не было. Последний get снова обращается к значению по умолчанию и выводит none. Полный вывод: none, req-7, none, каждое значение на своей строке.
Почему это важно
Так можно ограничить идентификатор запроса одной операцией, не оставляя его для последующих вызовов в том же контексте. Это короткая запись привычного set с последующим reset в finally. Токен относится к конкретному изменению, повторно сбрасывать переменную тем же токеном нельзя.
Код проверен в CPython 3.14.4.