John Belmonte <j...@neggie.net> added the comment:
My use case is for a non-async context manager, and if we take track_entry_and_exit as an example that's non-async as well. The explicit approach (e.g. separate base class for decorators applied to sync vs. async functions) doesn't seem ideal, because it precludes having a single context manager for both cases. track_entry_and_exit is an example where a context manager would want to decorate both types of functions. I'm not sure how big of a problem the iscoroutinefunction() limitation is-- in Trio style we don't pass around coroutines by normal functions. The `async` qualifier exists to make it clear when a function returns a coroutine, and ContextDecorator already doesn't work for the case of a regular function returning a coroutine. I think the scope here is to enhance ContextDecorator to work with async functions which are properly qualified with `async`. ---------- _______________________________________ 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
