[issue44482] Possible resource leeak in glob in non-refcount implementations

Serhiy Storchaka added the comment: New changeset 4861fdaf25f246eb9ee4e8161c15dad26efe895d by Serhiy Storchaka in branch '3.9': [3.9] bpo-44482: Fix very unlikely resource leak in glob in non-CPython implementations (GH-26843). (GH-26916) https://github.com/python/cpython/commit/4861fdaf25f2

[issue44482] Possible resource leeak in glob in non-refcount implementations

Change by Serhiy Storchaka : -- pull_requests: +25489 pull_request: https://github.com/python/cpython/pull/26916 ___ Python tracker ___

[issue44482] Possible resource leeak in glob in non-refcount implementations

Guido van Rossum added the comment: That explanation is still valid, I just hadn’t thought of it that way. -- ___ Python tracker ___ ___

[issue44482] Possible resource leeak in glob in non-refcount implementations

Terry J. Reedy added the comment: Nick Coughlin explained on issue 13814 msg151763 why he thought that making generators be context managers could/should not be done. "Generators deliberately don't support the context management protocol. This is so that they raise an explicit TypeError or At

[issue44482] Possible resource leeak in glob in non-refcount implementations

Guido van Rossum added the comment: I think this may be worth bringing up on python-dev. The solution currently is rather verbose. I like adding the with-protocol to generators. -- nosy: +Guido.van.Rossum ___ Python tracker

[issue44482] Possible resource leeak in glob in non-refcount implementations

Serhiy Storchaka added the comment: New changeset 38e021ab90b595945f15c59273c788f2f24053dc by Miss Islington (bot) in branch '3.10': bpo-44482: Fix very unlikely resource leak in glob in non-CPython implementations (GH-26843) (GH-26872) https://github.com/python/cpython/commit/38e021ab90b595

[issue44482] Possible resource leeak in glob in non-refcount implementations

Serhiy Storchaka added the comment: Yes. I added you Guido to the nosy list to attract attention to a general issue. If the generator owns resources, it should be guaranteed closed. Since generator do not support the context manager protocol, we need to use closing(). Using generators is com

[issue44482] Possible resource leeak in glob in non-refcount implementations

Change by miss-islington : -- nosy: +miss-islington nosy_count: 2.0 -> 3.0 pull_requests: +25447 pull_request: https://github.com/python/cpython/pull/26872 ___ Python tracker _

[issue44482] Possible resource leeak in glob in non-refcount implementations

Serhiy Storchaka added the comment: New changeset 5c7940257e1f611e7284fd504887bd29a63d0a94 by Serhiy Storchaka in branch 'main': bpo-44482: Fix very unlikely resource leak in glob in non-CPython implementations (GH-26843) https://github.com/python/cpython/commit/5c7940257e1f611e7284fd504887b

[issue44482] Possible resource leeak in glob in non-refcount implementations

Guido van Rossum added the comment: So this is a problem because the generator owns a resource that it will only release once its .close() method is called, right? And we have no control over when that happens -- we can't make it the responsibility of list() to close the iterator passed into

[issue44482] Possible resource leeak in glob in non-refcount implementations

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +25424 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26843 ___ Python tracker ___

[issue44482] Possible resource leeak in glob in non-refcount implementations

New submission from Serhiy Storchaka : There is possible resource leak in glob on alternate Python implementation witch do not use reference counting to immediate releasing resources. It is in the code names = list(_iterdir(dirname, dir_fd, dironly)) where _iterdir() is a generator funct