[Python-ideas] Allow manual creation of DirEntry objects

[Victor Stinner]

By the way, for all these reasons, I'm not really excited by Python
3.6 change exposing os.DirEntry ( https://bugs.python.org/issue27038
).

Victor

2016-08-17 1:11 GMT+02:00 Victor Stinner <victor.stinner at gmail.com>:
> 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