[Python-ideas] Allow manual creation of DirEntry objects

Victor Stinner victor.stinner at gmail.com
Tue Aug 16 19:11:21 EDT 2016


2016-08-16 23:13 GMT+02:00 Guido van Rossum <guido at python.org>:
> It sounds fine to just submit a patch to add and document the DirEntry
> constructor. I don't think anyone intended to disallow your use case, it's
> more likely that nobody thought of it.

Currently, the DirEntry constructor expects data which comes from
opendir/readdir functions on UNIX/BSD or FindFirstFile/FindNextFile
functions on Windows. These functions are not exposed in Python, so
it's unlikely that you can get expected value. The DirEntry object was
created to avoid syscalls in the common case thanks to data provided
by these functions.

But I guess that Brendan wants to create a DirEntry object which would
call os.stat() the first time that an attribute is read and then
benefit of the code. You loose the "no syscall" optimization, since at
least once syscall is needed.

In this case, I guess that the constructor should be
DirEntry(directory, entry_name) where os.path.join(directory,
entry_name) is the full path.

An issue is how to document the behaviour of DirEntry. Objects created
by os.scandir() would be "optimized", whereas objects created manually
would be "less optimized".

DirEntry is designed for os.scandir(), it's very limited compared to
pathlib. IMO pathlib would be a better candidate for "cached os.stat
results" with a full API to access the file system.

Victor


More information about the Python-ideas mailing list