René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Inconsistency in Cython object handling","articleBody":"# Bug report\n\n### Bug description:\n\nThere seems to be no consensus in the codebase on how to handle Cython objects. Both [`inspect.iscoroutinefunction()`](https://docs.python.org/3/library/inspect.html#inspect.iscoroutinefunction) and [`inspect.iscoroutine()`](https://docs.python.org/3/library/inspect.html#inspect.iscoroutine) are defined in the documentation for [`async def`](https://docs.python.org/3/reference/compound_stmts.html#async-def) functions and their objects, respectively. Therefore, the following code should be valid for them:\n\n```python\n#!/usr/bin/env python3\n\nimport inspect\n\n\nasync def coroutine_function() -\u003e None:\n    pass\n\n\ndef main() -\u003e None:\n    print(inspect.iscoroutinefunction(coroutine_function))  # `True`\n    print(inspect.iscoroutine(coro := coroutine_function()))  # `True`\n    coro.close()  # to avoid `RuntimeWarning`\n\n\nif __name__ == \"__main__\":\n    main()\n```\n\nThe same semantics are also expected by [typeshed](https://github.com/python/typeshed), which defines annotations as follows (and thus declares support for introspection):\n\n```python\n...\n@overload\ndef iscoroutinefunction(obj: object) -\u003e TypeGuard[Callable[..., CoroutineType[Any, Any, Any]]]: ...\n...\ndef iscoroutine(object: object) -\u003e TypeIs[CoroutineType[Any, Any, Any]]: ...\n...\n```\n\nHowever, after `cythonize -i -3`, the code changes its behavior:\n\n```python\nTrue  # `inspect.iscoroutinefunction()`\nFalse  # `inspect.iscoroutine()`\n```\n\nThis is because Cython uses its own objects for compiled functions and generators/coroutines/asynchronous generators. `inspect.is\u003cobject\u003e()` returns `True` only for uncompiled objects, as it relies on the [types](https://docs.python.org/3/library/types.html) module, but `inspect.is\u003cobject\u003efunction()` relies on checking function flags and handles function-like objects in a special way (for compatibility with Cython). As a result, we get the contradictory \"coroutine function does not return a coroutine\".\n\nThe problem is even deeper than one might imagine:\n\n1. Cython objects do not actually correspond completely to their counterparts from CPython. See cython/cython#7448.\n2. Mypy avoids using the [types](https://docs.python.org/3/library/types.html) module to infer the return type due to possible incompatibility with Cython. See python/mypy#18635 and python/mypy#20522.\n3. If the user wants to handle objects regardless of whether the module has been compiled or not, they have to come up with their own way of checking objects. See python/cpython#131983.\n\nWhat if we want to define a universal decorator that works for both regular and asynchronous functions? We could use [`inspect.iscoroutinefunction()`](https://docs.python.org/3/library/inspect.html#inspect.iscoroutinefunction), but it has very limited detection (in particular, it cannot detect object with `async def __call__()`), and library developers will only be able to rely on [`inspect.markcoroutinefunction()`](https://docs.python.org/3/library/inspect.html#inspect.markcoroutinefunction) after the Python 3.11's EOF. A frequently suggested alternative is to check the return value's type using [`inspect.isawaitable()`](https://docs.python.org/3/library/inspect.html#inspect.isawaitable), but this is actually shooting oneself in the foot, as it will lead to false positives for future-like objects (such as [asyncio future objects](https://docs.python.org/3/library/asyncio-future.html), which are also awaitable). The most logical solution would be to use [`inspect.iscoroutine()`](https://docs.python.org/3/library/inspect.html#inspect.iscoroutine), but it does not support Cython (and in fact, it is even less useful; see https://github.com/GrahamDumpleton/wrapt/issues/236#issuecomment-3655259023).\n\nIt seems to me that the question of whether the standard library (and related tools) should be Cython-aware has not been fully explored, which leads to such contradictions. I marked the issue as a bug, since it violates the expected behavior for any consistent interpretation.\n\n### CPython versions tested on:\n\n3.9, 3.10, 3.11, 3.12, 3.13, 3.14\n\n### Operating systems tested on:\n\nLinux","author":{"url":"https://github.com/x42005e1f","@type":"Person","name":"x42005e1f"},"datePublished":"2026-01-16T14:16:16.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":7},"url":"https://github.com/143908/cpython/issues/143908"}