homepage

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 <1451773580.55.0.0129656524332.issue25994@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2016年01月02日 22:26:20vstinnersetrecipients: + vstinner, benhoyt, serhiy.storchaka
2016年01月02日 22:26:20vstinnersetmessageid: <1451773580.55.0.0129656524332.issue25994@psf.upfronthosting.co.za>
2016年01月02日 22:26:20vstinnerlinkissue25994 messages
2016年01月02日 22:26:20vstinnercreate

AltStyle によって変換されたページ (->オリジナル) /