This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients benhoyt, serhiy.storchaka, vstinner
Date 2016-01-02.22:26:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>

If I recall correctly, this issue was discussed in the long review of os.scandir(): issue #22524.

"os.scandir() opens a file descriptor and closes it only in its destructor."

Hopefully, it's incorrect: it's closed when the iterator is exhausted. See how ScandirIterator_close() is used.

"This can causes file descriptor leaks in Python implementations without reference counting"

Destructors are part of the Python language. Are you aware of a Python implementation *never* calls destructors? I know that PyPy can call destructors "later", not necessary when the last reference to the object is removed. Do you think that we may reach the file descriptor limit because of that?

"We need to add the close() method to the scandir iterator (as in files and generators)."

Is it part of the iterator protocol? Or do you mean to explicitly call close()?

"It would be useful also to make it a context manager."

If we decide to add a close() method, it like the idea of also supporting the context manager protocol.

"In 3.5 we have to add a warning about this behavior."

Yeah, maybe we can elaborate the doc to explain how the file descriptor / Windows handle is used.
Date User Action Args
2016-01-02 22:26:20vstinnersetrecipients: + vstinner, benhoyt, serhiy.storchaka
2016-01-02 22:26:20vstinnersetmessageid: <>
2016-01-02 22:26:20vstinnerlinkissue25994 messages
2016-01-02 22:26:20vstinnercreate