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 <[email protected]>: > 2016-08-16 23:13 GMT+02:00 Guido van Rossum <[email protected]>: >> 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 _______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
