STINNER Victor added the comment: Hi,
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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25994> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
