[issue29302] add contextlib.AsyncExitStack

miss-islington added the comment: New changeset e5125f7b3b88d8d4814ed7bddbd4f34d24d763dd by Miss Islington (bot) in branch '3.8': Add Ilya Kulakov to Misc/ACKS. (GH-17130) https://github.com/python/cpython/commit/e5125f7b3b88d8d4814ed7bddbd4f34d24d763dd -- nosy: +miss-islington

[issue29302] add contextlib.AsyncExitStack

Change by miss-islington : -- pull_requests: +16649 pull_request: https://github.com/python/cpython/pull/17138 ___ Python tracker ___

[issue29302] add contextlib.AsyncExitStack

Benjamin Peterson added the comment: New changeset d6d6e2aa0249bb661541705335ddbb97a53d64c8 by Benjamin Peterson (Ilya Kulakov) in branch 'master': Add Ilya Kulakov to Misc/ACKS. (GH-17130) https://github.com/python/cpython/commit/d6d6e2aa0249bb661541705335ddbb97a53d64c8 -- nosy:

[issue29302] add contextlib.AsyncExitStack

Change by Ilya Kulakov : -- pull_requests: +16640 pull_request: https://github.com/python/cpython/pull/17130 ___ Python tracker ___

[issue29302] add contextlib.AsyncExitStack

Yury Selivanov added the comment: Thank you Alexander and Ilya! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue29302] add contextlib.AsyncExitStack

Yury Selivanov added the comment: New changeset 1aa094f74039cd20fdc7df56c68f6848c18ce4dd by Yury Selivanov (Ilya Kulakov) in branch 'master': bpo-29302: Implement contextlib.AsyncExitStack. (#4790)

[issue29302] add contextlib.AsyncExitStack

Nick Coghlan added the comment: Explicitly noting some API design decisions from the review of https://github.com/python/cpython/pull/4790: 1. AsyncExitStack will define __aenter__ and __aexit__ but *not* __enter__ and __exit. This makes it unambiguous which form of with

[issue29302] add contextlib.AsyncExitStack

Cheryl Sabella added the comment: Looks like AbstractAsyncContextManager is defined in issue #30241. -- ___ Python tracker ___

[issue29302] add contextlib.AsyncExitStack

Ilya Kulakov added the comment: Charyl, I made the PR. Where is the AbstractAsyncContextManager? I see that typing.py references it, but there is no actual implementation. -- ___ Python tracker

[issue29302] add contextlib.AsyncExitStack

Change by Ilya Kulakov : -- keywords: +patch pull_requests: +4690 stage: needs patch -> patch review ___ Python tracker ___

[issue29302] add contextlib.AsyncExitStack

Change by Cheryl Sabella : -- stage: -> needs patch ___ Python tracker ___ ___

[issue29302] add contextlib.AsyncExitStack

Cheryl Sabella added the comment: Alexander, Did you want to submit a PR for this? -- nosy: +csabella ___ Python tracker ___

[issue29302] add contextlib.AsyncExitStack

Change by privatwolke : -- nosy: +privatwolke ___ Python tracker ___ ___

[issue29302] add contextlib.AsyncExitStack

Changes by Nathaniel Smith : -- nosy: +njs ___ Python tracker ___ ___ Python-bugs-list

[issue29302] add contextlib.AsyncExitStack

Alexander Mohr added the comment: let me know if I need to do anything -- ___ Python tracker ___ ___

[issue29302] add contextlib.AsyncExitStack

Nick Coghlan added the comment: While it *may* be possible to do something simpler for test purposes where performance isn't a major concern, fully supporting type() level mocking basically requires bringing the equivalent of wrapt object proxies into the standard library:

[issue29302] add contextlib.AsyncExitStack

Yury Selivanov added the comment: >> but at the same time rejected by the 'async with' statement. > Perhaps unittest.mock (or type) needs to be adjusted to allow mocking via > spec= without subclassing? Maybe. You should try to find discussions around this topic on python mailing lists and

[issue29302] add contextlib.AsyncExitStack

Ilya Kulakov added the comment: > but at the same time rejected by the 'async with' statement. Perhaps unittest.mock (or type) needs to be adjusted to allow mocking via spec= without subclassing? > By all means you can submit a PR! I'll take a look then. --

[issue29302] add contextlib.AsyncExitStack

Yury Selivanov added the comment: > I'm not sure about type() to get a class object and calling __aenter__, > __aexit__ through it: that makes it hard to mock these classes as Mock's > spec= relies on __class__ and type() seem to ignore it (learned it a hard way. Looking up __dunder__ methods

[issue29302] add contextlib.AsyncExitStack

Ilya Kulakov added the comment: I'm not sure about type() to get a class object and calling __aenter__, __aexit__ through it: that makes it hard to mock these classes as Mock's spec= relies on __class__ and type() seem to ignore it (learned it a hard way. Yury, I could take a second look and

[issue29302] add contextlib.AsyncExitStack

Yury Selivanov added the comment: Overall, the approach looks fine. Alexander, do you want to make a PR to start working on adding this to 3.7? -- versions: -Python 3.6 ___ Python tracker

[issue29302] add contextlib.AsyncExitStack

Alexander Mohr added the comment: ok I've updated the gist with a base class and sync + async sub-classes. The way it worked out I think is nice because we can have the same method names across both sync+async. Let me know what you guys think! btw, it seems the

[issue29302] add contextlib.AsyncExitStack

Changes by STINNER Victor : -- nosy: -haypo ___ Python tracker ___ ___

[issue29302] add contextlib.AsyncExitStack

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___

[issue29302] add contextlib.AsyncExitStack

Yury Selivanov added the comment: Looking at the code: we don't need to use iscoroutinefunction at all. If we had separate methods for sync and async context managers, you can store the flag if a function is async or sync along with it. So _exit_callbacks should store tuples `(is_async,

[issue29302] add contextlib.AsyncExitStack

Yury Selivanov added the comment: Alexander, You don't need asyncio.isocoroutinefunction. Please use inspect.iscoroutinefunction and inspect.iscoroutine. Nick, I'm +1 to have a separate class AsyncExitStack. > - assume everything passed to it is a coroutine or an async context manager >

[issue29302] add contextlib.AsyncExitStack

Alexander Mohr added the comment: Thanks for the feedback Nick! If I get a chance I'll see about refactoring my gist into a base class and two sub-classes with the async supporting non-async but not vice-versa. I think it will be cleaner. Sorry I didn't spend too much effort on the existing

[issue29302] add contextlib.AsyncExitStack

Nick Coghlan added the comment: I quite like the idea of enhancing the existing ExitStack to also handle asynchronous operations rather than having completely independent implementations. However, a separate object may end up being simpler in practice as it allows developers to more

[issue29302] add contextlib.AsyncExitStack

Changes by Nick Coghlan : -- nosy: +giampaolo.rodola, gvanrossum, haypo, ncoghlan, yselivanov ___ Python tracker ___

[issue29302] add contextlib.AsyncExitStack

Vedran Čačić added the comment: An example from "real life": I recently needed this when implementing a demo of dining philosophers using asyncio (when the order of locks should depend on comparison of fork ids, not be static). Of course, it wasn't hard to implement it directly, but still, it

[issue29302] add contextlib.AsyncExitStack

Alexander Mohr added the comment: created gist: https://gist.github.com/thehesiod/b8442ed50e27a23524435a22f10c04a0 I've now updated the imple to support both __aenter__/__aexit__ and __enter__/__exit__ so I don't need two ExitStacks -- ___ Python

[issue29302] add contextlib.AsyncExitStack

Changes by Alexander Mohr : Removed file: http://bugs.python.org/file46322/exit_stack.py ___ Python tracker ___

[issue29302] add contextlib.AsyncExitStack

New submission from Alexander Mohr: ExitStack is a really useful class and would be a great to have an async version. I've gone ahead and created an implementation based on the existing Python 3.5.2 implementation. Let me know what you guys think. I think it would be possible to combine