Repository navigation
Add dir_fd to os.path.lexists() & os.path.isdir() #117967
Description
Activity
- addedtype-featureA feature request or enhancementA feature request or enhancement
on Apr 17, 2024 - addedstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
on Apr 17, 2024 cc @serhiy-storchaka before I start implementing this: is this something you would support?
It is trivially implemented via
os.stat.globimplements private helpers for historical reasons -- they should behave exactly likeos.pathversions.If there will be other uses of such functions in several different places, it will be worth to add this feature.
Reacted by Erlend E. AaslandIt is trivially implemented via
os.stat.Note that that's overkill on Windows.You're right because dir_fd isn't supported on Windows, sorry.glob implements private helpers for historical reasons
They could still be simplified in that case:
def _lexists(pathname, dir_fd): # Same as os.path.lexists() return os.path.lexists(pathname, dir_fd=dir_fd) def _isdir(pathname, dir_fd): # Same as os.path.isdir() return os.path.isdir(pathname, dir_fd=dir_fd)
@barneygale, do you think this can speed things up?No, it can't, but it could also be used for #117737.Note: nt._path_isdir() (& nt._path_lexists() when #117842 lands) would also need to be updated.
The builtin
_path_*functions on Windows would have to be modified to raiseNotImplementedErrorif the newdir_fdargument isn'tNone.FYI, the NT kernel supports opening relative to a handle, which the Windows API makes use of when opening relative to the working directory. However, it's not directly exposed in the Windows API. A fundamental problem is that ".." components are resolved logically on Windows by the user-mode runtime library. Thus using a safe open on NT requires that the normalized relative path doesn't begin with a ".." component.
Reacted by Nice ZombiesI don't feel strongly about it. I note it would be the first
os.pathfunction to acceptdir_fd.The builtin
_path_*functions on Windows would have to be modified to raiseNotImplementedErrorif the newdir_fdargument isn'tNone.I see, I assumed Windows supported it too. Then it can only be used for refactoring
glob.I note it would be the first
os.pathfunction to acceptdir_fd.At the moment it only seems to be needed for
glob, so I'll leave it up to serhiy to decide.I'm closing this as there's not much support. Feel free to re-open when you change your mind.
Reacted by Erlend E. Aasland
Feature or enhancement
Proposal:
globcurrently needs its own implementation ofos.path.lexists()&os.path.isdir()to supportdir_fd:cpython/Lib/glob.py
Lines 201 to 222 in f74e512
We could refactor this by adding
dir_fdtoos.path.lexists()&os.path.isdir():Note:
nt._path_isdir()(&nt._path_lexists()when #117842 lands) need to raise an error for this.Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response