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
