stubgen generates stubs for `@asynccontextmanager` functions that mypy itself rejects
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 20.6k
- フォーク
- 3.3k
- PR マージ指標
- PR 指標を取得中
説明
Bug Report
stubgen copies @asynccontextmanager and the async def keyword verbatim into the generated .pyi. Because a stub body has no yield, mypy then classifies the stubbed function as a coroutine function returning AsyncIterator[T] rather than as an async generator function, and rejects the decorator application.
The result is that stubgen emits a stub which mypy — the same version, with default settings — reports an error on. Source that type-checks cleanly produces a stub that does not.
To Reproduce
# cm.py
from collections.abc import AsyncIterator
from contextlib import asynccontextmanager
@asynccontextmanager
async def ctx() -> AsyncIterator[int]:
yield 1
$ mypy cm.py
Success: no issues found in 1 source file
$ stubgen -o out cm.py
Processed 1 modules
Generated out/cm.pyi
$ cat out/cm.pyi
from collections.abc import AsyncIterator
from contextlib import asynccontextmanager
@asynccontextmanager
async def ctx() -> AsyncIterator[int]: ...
$ mypy out/cm.pyi
out/cm.pyi:4: error: Argument 1 to "asynccontextmanager" has incompatible type "Callable[[], Coroutine[Any, Any, AsyncIterator[int]]]"; expected "Callable[[], AsyncIterator[Never]]" [arg-type]
Found 1 error in 1 file (checked 1 source file)
The same happens for methods, and with AsyncGenerator[T, None] in place of AsyncIterator[T].
Expected Behavior
stubgen output should type-check under the mypy version that produced it. For an @asynccontextmanager-decorated async generator, that means emitting one of the two spellings the typing docs sanction for stubs — either dropping async:
@asynccontextmanager
def ctx() -> AsyncIterator[int]: ...
or dropping the decorator and declaring the decorated result, as typeshed does:
from contextlib import AbstractAsyncContextManager
def ctx() -> AbstractAsyncContextManager[int]: ...
Both of these are accepted by mypy 2.3.0.
Actual Behavior
out/cm.pyi:4: error: Argument 1 to "asynccontextmanager" has incompatible type "Callable[[], Coroutine[Any, Any, AsyncIterator[int]]]"; expected "Callable[[], AsyncIterator[Never]]" [arg-type]
Your Environment
- Mypy version used: 2.3.0 (compiled: yes)
- Mypy command-line flags: none (
mypy out/cm.pyi); stub produced withstubgen -o out cm.py - Mypy configuration options from
mypy.ini(and other config files): none - Python version used: 3.11.15
Additional notes
This is a change in behaviour from 1.15.0. That version's stubgen omitted the decorator entirely:
# stubgen 1.15.0
async def ctx() -> AsyncIterator[int]: ...
which is also lossy, but happens to type-check, so the problem only becomes visible on 2.3.0 once the decorator is preserved.
The synchronous case is unaffected — @contextmanager over def f() -> Iterator[T] round-trips through stubgen and type-checks on 2.3.0, because there is no async keyword to change how the return type is interpreted.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
stubgen のエントリーポイントから開始し、報告にある @asynccontextmanager の例を cm.py で使って問題を再現します。非同期ジェネレーター関数とメソッドについて生成された .pyi の出力を比較し、その後、生成されたスタブに対して mypy を実行します。このケースで生成されたスタブが意図されたコンテキストマネージャーの型付けを維持したまま、エラーなしで型チェックを通れば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- cli, tooling
- issue の種類
- バグ
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 活発さ
- 静か
- 明瞭さ
- 明確に書かれている
- 初心者へのやさしさ
- 72/100