[issue37398] contextlib.ContextDecorator decorating async functions

Nick Coghlan added the comment: You are correct that this proposal is technically rejected, rather than being a true duplicate of the AsyncContextManager addition. The core problem with the automatic inference idea is that it isn't possible for the standard library to reliably distinguish

[issue37398] contextlib.ContextDecorator decorating async functions

John Belmonte added the comment: > bpo-40816 took the much simpler approach of introducing a separate > contextlib.AsyncContextDecorator class How do I apply AsyncContextDecorator to the use case of wrapping either a sync or async function with a synchronous context manager? --

[issue37398] contextlib.ContextDecorator decorating async functions

Nick Coghlan added the comment: bpo-40816 took the much simpler approach of introducing a separate contextlib.AsyncContextDecorator class. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Add missed AsyncContextDecorator to contextlib versions:

[issue37398] contextlib.ContextDecorator decorating async functions

Change by Krzysztof Wróblewski : -- nosy: +Krzysztof Wróblewski ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue37398] contextlib.ContextDecorator decorating async functions

Nick Coghlan added the comment: The query in #37743 highlights that generator functions and other wrapped iterator factories actually face a similar problem: they need the function body to contain "yield from wrapped(*args, **kwargs)" if the CM is going to be closed after the iterator

[issue37398] contextlib.ContextDecorator decorating async functions

Nick Coghlan 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

[issue37398] contextlib.ContextDecorator decorating async functions

Yury Selivanov added the comment: > I think a simple iscoroutinefunction check will be pretty close to 100% > matching what users expect. Yes, "pretty close", but not reliable. :) E.g. I can easily design a decorator that when applied first would break the proposed iscoroutinefunction

[issue37398] contextlib.ContextDecorator decorating async functions

Nathaniel Smith added the comment: @Yury: depends on what you mean by "100% reliable" :-). Like I said above, I'm normally super against automagic detection of sync-vs-async functions because of all the edge cases where it goes wrong, but in this specific case where people are writing a

[issue37398] contextlib.ContextDecorator decorating async functions

Yury Selivanov added the comment: > I hear you on the semantic confusion, but is a single check at definition > time really that expensive? Do you know how to make that single check 100% reliable? -- ___ Python tracker

[issue37398] contextlib.ContextDecorator decorating async functions

Nathaniel Smith added the comment: > I wouldn't be OK with magic switching in the behaviour of ContextDecorator > (that's not only semantically confusing, it's also going to make the > contextlib function wrappers even slower than they already are). I hear you on the semantic confusion, but

[issue37398] contextlib.ContextDecorator decorating async functions

Nick Coghlan added the comment: I wouldn't be OK with magic switching in the behaviour of ContextDecorator (that's not only semantically confusing, it's also going to make the contextlib function wrappers even slower than they already are). I'm also entirely unclear on what you would expect

[issue37398] contextlib.ContextDecorator decorating async functions

Andrew Svetlov added the comment: I still think that iscoroutinefunction should not be used for async/sync decoration type autodetection. A day ago stuck with a case when decorator used iscoroutinefunction() for separation but returned a regular function wrapper that returns awaitable in

[issue37398] contextlib.ContextDecorator decorating async functions

Nathaniel Smith added the comment: There are two different axes of sync/async here, and it's important not to mix them up: the context manager could be sync or async, and the function that's being decorated could be sync or async. This issue is about the case where you have a sync context

[issue37398] contextlib.ContextDecorator decorating async functions

John Belmonte added the comment: I was caught by this again, indirectly via @contextmanager. If I define a non-async context manager using @contextmanager, I expect the decorator support to work on async functions. I.e. the following should be equivalent: ``` async def foo(): with

[issue37398] contextlib.ContextDecorator decorating async functions

John Belmonte 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

[issue37398] contextlib.ContextDecorator decorating async functions

Andrew Svetlov added the comment: Got you. iscoroutinefunction() is not reliable: it detects async functions only but fails if we have a regular function that returns awaitable object. I think AsyncContextDecorator is needed here to explicitly point that you want to wrap async function.

[issue37398] contextlib.ContextDecorator decorating async functions

John Belmonte added the comment: PerfTimer is a reusable, non-reentrant context manager implemented as a class. There are already use cases of ContextDecorator described in the contextlib documentation, such as the track_entry_and_exit logger. What reason would you have for such context

[issue37398] contextlib.ContextDecorator decorating async functions

Andrew Svetlov added the comment: Sorry, I still have no idea what is the code for PerfTimer class. -- ___ Python tracker ___ ___

[issue37398] contextlib.ContextDecorator decorating async functions

John Belmonte added the comment: I have a context manager used for timing sections of code or whole functions (when used as a decorator). It's aware of the Trio async/await scheduler and is able to exclude periods of time where the task is not executing. The context manager itself is not

[issue37398] contextlib.ContextDecorator decorating async functions

Andrew Svetlov added the comment: I wonder why do you need it? What is your use case? A code snippet can help a lot. -- ___ Python tracker ___

[issue37398] contextlib.ContextDecorator decorating async functions

Change by Karthikeyan Singaravelan : -- nosy: +asvetlov, xtreak, yselivanov versions: +Python 3.9 ___ Python tracker ___ ___

[issue37398] contextlib.ContextDecorator decorating async functions

New submission from John Belmonte : A case came up where I'd like a non-async context manager to be able to decorate both regular and async functions. I wonder why contextlib.ContextDecorator doesn't just support both cases. The implementation seems straightforward, switching on