Message351073
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. |
|
Date |
User |
Action |
Args |
2019-09-03 08:15:02 | ncoghlan | set | recipients:
+ ncoghlan, njs, asvetlov, yselivanov, xtreak, John Belmonte |
2019-09-03 08:15:02 | ncoghlan | set | messageid: <1567498502.53.0.949028371449.issue37398@roundup.psfhosted.org> |
2019-09-03 08:15:02 | ncoghlan | link | issue37398 messages |
2019-09-03 08:15:02 | ncoghlan | create | |
|