[issue40213] contextlib.aclosing()

John Belmonte added the comment: merged for Python 3.10 -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue40213] contextlib.aclosing()

Change by John Belmonte : -- pull_requests: +21633 versions: +Python 3.10 -Python 3.9 pull_request: https://github.com/python/cpython/pull/21545 ___ Python tracker ___

[issue40213] contextlib.aclosing()

Change by John Belmonte : -- keywords: +patch nosy: +jbelmonte nosy_count: 9.0 -> 10.0 pull_requests: +21613 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22640 ___ Python tracker

[issue40213] contextlib.aclosing()

Dong-hee Na added the comment: see https://bugs.python.org/issue41229 -- nosy: +corona10 ___ Python tracker ___ ___

[issue40213] contextlib.aclosing()

Change by Nikolay Bryskin : -- nosy: +nikicat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40213] contextlib.aclosing()

Alex Grönholm added the comment: I think the most important use case for these is closing async generators deterministically, since they don't support the async context manager protocol. -- ___ Python tracker

[issue40213] contextlib.aclosing()

John Belmonte added the comment: 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. --

[issue40213] contextlib.aclosing()

John Belmonte added the comment: 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. -- ___ Python tracker

[issue40213] contextlib.aclosing()

Alex Grönholm added the comment: 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. -- ___ Python tracker

[issue40213] contextlib.aclosing()

Serhiy Storchaka added the comment: 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

[issue40213] contextlib.aclosing()

Change by Karthikeyan Singaravelan : -- nosy: +asvetlov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40213] contextlib.aclosing()

Alex Grönholm added the comment: Seconded. -- nosy: +alex.gronholm ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40213] contextlib.aclosing()

Change by Nathaniel Smith : -- nosy: +ncoghlan, yselivanov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40213] contextlib.aclosing()

New submission from John Belmonte : 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