[issue29679] Add @contextlib.asynccontextmanager

Changes by Yury Selivanov : -- resolution: -> fixed stage: -> resolved status: open -> closed type: -> enhancement ___ Python tracker ___ _

[issue29679] Add @contextlib.asynccontextmanager

Yury Selivanov added the comment: New changeset 2e624690bd74071358566300b7ef0bc45f444a30 by Yury Selivanov (Jelle Zijlstra) in branch 'master': bpo-29679: Implement @contextlib.asynccontextmanager (#360) https://github.com/python/cpython/commit/2e624690bd74071358566300b7ef0bc45f444a30 ---

[issue29679] Add @contextlib.asynccontextmanager

Nick Coghlan added the comment: For anyone interested in the question of backports, I moved that discussion over to the contextlib2 tracker: https://github.com/jazzband/contextlib2/issues/12 -- ___ Python tracker

[issue29679] Add @contextlib.asynccontextmanager

Yury Selivanov added the comment: > so it would need to split any code using "async def" and "await" out to a > separate file that only gets imported on 3.5+ (and similarly only run the > corresponding test cases on 3.5+). This seems doable. I'd only vote to keep contextlib.py as one file in

[issue29679] Add @contextlib.asynccontextmanager

Nick Coghlan added the comment: Something that occurred to me as being a bit tricky to handle here is the backport to contextlib2: that maintains compatibility with 2.6+, so it would need to split any code using "async def" and "await" out to a separate file that only gets imported on 3.5+ (an

[issue29679] Add @contextlib.asynccontextmanager

Nick Coghlan added the comment: In the specific case of contextlib, most of the APIs should be able to transparently support async/await without negatively impacting their synchronous behaviour, so after the python-dev discussion, I think one module with separate sync and async test suites is

[issue29679] Add @contextlib.asynccontextmanager

Raymond Hettinger added the comment: At third alternative is to create an asynctools module to collect together tools that work with the async keyword but aren't dependent on asyncio. -- ___ Python tracker ___

[issue29679] Add @contextlib.asynccontextmanager

Changes by STINNER Victor : -- nosy: -haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue29679] Add @contextlib.asynccontextmanager

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue29679] Add @contextlib.asynccontextmanager

Yury Selivanov added the comment: > In formulating my question for the list, it occurred to me that while > asynccontextmanager doesn't need to depend on asyncio, the AsyncExitStack > proposed in issue 29302 likely will, which pushes me towards favouring the > `asyncio.contextlib.asynccontextm

[issue29679] Add @contextlib.asynccontextmanager

Nick Coghlan added the comment: python-dev thread: https://mail.python.org/pipermail/python-dev/2017-March/147501.html In formulating my question for the list, it occurred to me that while asynccontextmanager doesn't need to depend on asyncio, the AsyncExitStack proposed in issue 29302 likely

[issue29679] Add @contextlib.asynccontextmanager

Nick Coghlan added the comment: It's probably worth a python-dev discussion, but I personally draw the line at "Does this need to import 'asyncio'?". If it does, then that's a clear dependency inversion, and the functionality doesn't belong in a relatively low level module like contextlib. If

[issue29679] Add @contextlib.asynccontextmanager

Raymond Hettinger added the comment: Nick, do you think this belongs in contextlib to be side-by-side with @contextmanager or would it be better to group all async tools in their own module. It seems to me that people are going to ask for an async version of everything, effectively shadowi

[issue29679] Add @contextlib.asynccontextmanager

Jelle Zijlstra added the comment: Thanks, I'll address your PR comments. issue 29302 is asking for AsyncExitStack, but that can be an independent change. I haven't personally felt the need for AsyncExitStack. -- ___ Python tracker

[issue29679] Add @contextlib.asynccontextmanager

Nick Coghlan added the comment: The general idea seems reasonable to me, and I've added some specific code level feedback on the PR. A related question to this one would be whether or not it may make sense to develop a more async-friendly variant of contextlib.ExitStack (I don't currently wri

[issue29679] Add @contextlib.asynccontextmanager

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

[issue29679] Add @contextlib.asynccontextmanager

Changes by Jelle Zijlstra : -- pull_requests: +307 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue29679] Add @contextlib.asynccontextmanager

New submission from Jelle Zijlstra: An async equivalent of @contextmanager would be an obvious use case for async generators and the async with statement. In my own code, I have several async context objects that could have been written more concisely if @asynccontextmanager was available. I'