Title: contextlib.aclosing()
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.10
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: John Belmonte, alex.gronholm, asvetlov, corona10, jbelmonte, ncoghlan, nikicat, njs, serhiy.storchaka, yselivanov
Priority: normal Keywords: patch

Created on 2020-04-07 02:13 by John Belmonte, last changed 2021-06-11 08:36 by John Belmonte. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 22640 closed jbelmonte, 2020-10-10 15:27
PR 21545 John Belmonte, 2020-10-11 23:42
Messages (9)
msg365885 - (view) Author: John Belmonte (John Belmonte) Date: 2020-04-07 02:13
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().
msg365894 - (view) Author: Alex Grönholm (alex.gronholm) * Date: 2020-04-07 07:28
msg372905 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-07-03 05:22
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.
msg372908 - (view) Author: Alex Grönholm (alex.gronholm) * Date: 2020-07-03 07:31
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.
msg372909 - (view) Author: John Belmonte (John Belmonte) Date: 2020-07-03 07:54
Given the lack of deterministic cleanup for iterators (, aclosing() is the way to ensure deterministic cleanup given any API using async iteration.
msg372910 - (view) Author: John Belmonte (John Belmonte) Date: 2020-07-03 08:00
highlighting from PEP 533:

> Async generators cannot do cleanup at all without some mechanism for deterministic cleanup that people will actually use, and async generators are particularly likely to hold resources like file descriptors.
msg372911 - (view) Author: Alex Grönholm (alex.gronholm) * Date: 2020-07-03 08:10
I think the most important use case for these is closing async generators deterministically, since they don't support the async context manager protocol.
msg377257 - (view) Author: Dong-hee Na (corona10) * (Python committer) Date: 2020-09-21 14:31
msg395618 - (view) Author: John Belmonte (John Belmonte) Date: 2021-06-11 08:36
merged for Python 3.10
Date User Action Args
2021-06-11 08:36:18John Belmontesetstatus: open -> closed
resolution: fixed
messages: + msg395618

stage: patch review -> resolved
2020-10-11 23:42:07John Belmontesetversions: + Python 3.10, - Python 3.9
pull_requests: + pull_request21633
2020-10-10 15:27:06jbelmontesetkeywords: + patch
nosy: + jbelmonte

pull_requests: + pull_request21613
stage: patch review
2020-09-21 14:31:58corona10setnosy: + corona10
messages: + msg377257
2020-09-21 14:19:26nikicatsetnosy: + nikicat
2020-07-03 08:10:16alex.gronholmsetmessages: + msg372911
2020-07-03 08:00:20John Belmontesetmessages: + msg372910
2020-07-03 07:54:37John Belmontesetmessages: + msg372909
2020-07-03 07:31:45alex.gronholmsetmessages: + msg372908
2020-07-03 05:22:18serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg372905
2020-04-07 07:45:27xtreaksetnosy: + asvetlov
2020-04-07 07:28:30alex.gronholmsetnosy: + alex.gronholm
messages: + msg365894
2020-04-07 02:14:59njssetnosy: + ncoghlan, yselivanov
2020-04-07 02:13:32John Belmontecreate