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
contextlib.aclosing() #84394
Comments
Please add aclosing() to contextlib, the async equivalent of closing(). It's needed to ensure deterministic call of aclose() on the resource object at block exit. It's been available in the async_generator module for some time. However that module is intended to provide async generators to Python 3.5, so it's odd for apps using modern Python versions to depend on it only for aclosing(). |
Seconded. |
Do you have use cases or want to add it for pure "symmetry" reasons? contextlib.closing() was added when context managers were new, and many classes that own resources did have the close() method but did not support the context manager protocol. Now most of these classes are context managers, and new classes usually are written with the support of the context manager protocol from beginning. The usefulness of contextlib.closing() is much smaller now. |
They are both still useful, particularly with third party libraries. Just yesterday I found myself looking for aclosing() in contextlib, only to remember this issue. |
Given the lack of deterministic cleanup for iterators (https://www.python.org/dev/peps/pep-0533/), aclosing() is the way to ensure deterministic cleanup given any API using async iteration. |
highlighting from PEP-533:
|
I think the most important use case for these is closing async generators deterministically, since they don't support the async context manager protocol. |
merged for Python 3.10 |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: