Nick Coghlan <ncogh...@gmail.com> added the comment:
It isn't the simple case where the auto-detection idea concerns me, it's decorator stacking cases like: @outer @magic_detection @inner_forces_async def sync_native_api(): ... (With the original asyncio.coroutine being one example, but there are other situations where this comes up, like a wrapper that bundles synchronous calls up into an executor invocation) That said, I'd be completely fine with a combination where: * ContextDecorator grew a coroutine() classmethod (open to suggestions for bikeshed colours) * The regular ContextDecorator constructor emitted a warning suggesting "cls.coroutine" when it was applied to a synchronous function Then the original example would provide distinct spellings for the sync and async case, without the definition of PerfTimer needing to change: @PerfTimer.coroutine('query_async') async def query_or_throw(self, q): return _parse_result(await self._send_query(q)) @PerfTimer('query_sync') def query_or_throw(self, q): return _parse_result(self._send_query_sync(q)) That way we're still refusing to guess in the face of ambiguity (does the user want the coroutine version of the context manager, or did they accidentally mix a potentially blocking synchronous context manager into their async code?), but the warning can be usefully explicit regarding how to resolve the ambiguity. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37398> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com