-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decide how to backport 3.7 async context management support #12
Comments
Can't imagine how you can manage this to work on 3.5 without yield support inside coroutines. I'll subscribe to this thread to see any useful ideas for that. |
But supporting at least 3.6 would be great. I am already using personal package for this, and could provide a PR for |
Like Nick, I'd prefer keeping a single package. Having fewer packages with similar purposes makes it easier for people to decide what package to install. The implementation would probably involve making contextlib2 into a package, organized something like this:
Yes, this probably can't be backported to 3.5 (maybe using https://github.com/njsmith/async_generator would work?). However, other future async enhancements to contextmanager, like AsyncExitStack, could be backported to 3.5 (and even earlier if you want to use yield from). |
Using another libraries with their own logic ( |
For now, I've reworded the issue to just target 3.6+. However, we can keep the possibility of supporting earlier versions in mind as we consider possible solutions.
|
FWIW, I use a home grown version of this all the time on 3.5, via https://github.com/njsmith/async_generator. For example, This code is sometimes a bit annoying to maintain, so I'd be happy to delegate to contextlib2 :-). OTOH there might be a few challenges. The homegrown changes in my version are:
I don't think these are showstoppers, just figured put them on the radar. |
FYI, since the only piece I was missing from async_generator was an I'd be happy to help with a proper backport. |
I think between @sorcio's While there a few APIs it would be nice to extract and make universally available, that could be considered as a separate issue after the initial 3.6+ option was implemented. |
With @jayvdb submitting the synchronous enhancements as a separate PR (which I'm about to release as 0.6.0) that opens up a new alternative: what if contextlib2 0.7.0 were to just drop support for all versions prior to 3.6, leaving users of old Python versions on 0.6.0 indefinitely? |
@ncoghlan does the Python 3.5 EOL change anything? |
@graingert It makes me even happier with the idea of 0.7.0 being 3.6+ only, which means it should be possible to just sync the latest version over from CPython 3.10 (modulo keeping the contextlib2 APIs that never graduated to the stdlib version) |
I've merged the changes from #29 (switch to CalVer, set the minimum version to 3.6), clearing the way for the Python 3.10 version to be sync'ed over. With the 2.x compatibility code gone, I'm hoping that will now be a lot simpler than it used to be. |
PR is up #32 CI mostly looks good, just need to check what's up with PyPy3 |
…-3.10 Issue #12: sync module from CPython 3.10
As far as I can tell, the PyPy3 issue was a bug in the stdlib test suite (assuming the use of a refcounted GC): https://bugs.python.org/issue44515 CPython PR submitted at python/cpython#26910 |
Bah, forgot to include the docs updates for the new APIs |
…lib-docs Issue #12: Sync API documentation from Python 3.10
OK, docs are also updated now. |
Python 3.7 added async/await support to the contextlib module (e.g.
asyncontextmanager
andAsyncExitStack
), and then Python 3.10 added more (e.g.aclosing
).This raised the question of how to backport those features to 3.6+ (the first version with support for
yield
insideasync def
).The answer turned out to be "procrastinate on the question for 4+ years, so it became feasible to simply drop support for Python 3.5 and earlier, and use the async generator code as-is".
(Issue description updated Jun 2021 to describe what actually happened, rather than the more complicated alternatives I was considering to allow adding the new async features without dropping support for Python 3.5 and earlier)
The text was updated successfully, but these errors were encountered: