You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
nt is the module name for posixmodule.c on Windows, so I'm changing the title to reference ntpath instead.
Regarding nt, two of its built-in functions are exposed directly in ntpath. _isdir is imported as isdir, so it needs a wrapper to support __fspath__. Only pathlib uses _getfinalpathname, so for now I think it can be handled there. There's also nt._getdiskusage, which is only used by shutil.disk_usage. For some reason the PEP doesn't mention updating shutil to support __fspath__.
Sorry, I must have missed or misunderstood something. PEP-519 discusses modifying os.path. For the os module it only discusses adding fspath and updating fsencode and fsdecode. It also discusses a new PyOS_FSPath C API, but without any discussion regarding its use in the implementation of the posix / nt module, or regarding what built-in os functions should support __fspath__.
I think that if some high-level function uses os.path, it likely should convert Path argument to str either because the path should be saved as a string, or for performance if multiple os.path functions are called with the same argument. Note, that some os.path functions will implicitly support path objects if the posix module support it.
Let first find the functions that need path objects support in os.path.
The expected scenario, and the purpose of os.fspath(), is to enable high-level libraries to not know or care if they receive a pathlib object or a string.
In other words, they already have os.path.join() and os.path.split() calls, and currently break noisily if a pathlib.Path is passed in; by enhancing os.path to accept a pathlib.Path object that high-level library can start working with pathlib.Path objects without changing a thing, which means the user of that library can use pathlib.Path painlessly.
Unless I have seriously misunderstood something, os.path will be changed to work with __fspath__ objects.
os.path will be updated to work with __fspath__() as specified by Guido as part of the conversation for PEP-519 (IOW listing os.path as being updated in PEP-519 is not an accident).
Activity
eryksun commentedon Jun 3, 2016
nt is the module name for posixmodule.c on Windows, so I'm changing the title to reference ntpath instead.
Regarding nt, two of its built-in functions are exposed directly in ntpath. _isdir is imported as isdir, so it needs a wrapper to support __fspath__. Only pathlib uses _getfinalpathname, so for now I think it can be handled there. There's also nt._getdiskusage, which is only used by shutil.disk_usage. For some reason the PEP doesn't mention updating shutil to support __fspath__.
[-]Support path objects in the nt module[/-][+]Support path objects in the ntpath module[/+]serhiy-storchaka commentedon Jun 3, 2016
Please don't change os.path until all other module will be changed. It may be that os.path would not need any change at all.
eryksun commentedon Jun 3, 2016
Sorry, I must have missed or misunderstood something. PEP-519 discusses modifying os.path. For the os module it only discusses adding fspath and updating fsencode and fsdecode. It also discusses a new PyOS_FSPath C API, but without any discussion regarding its use in the implementation of the posix / nt module, or regarding what built-in os functions should support __fspath__.
ethanfurman commentedon Jun 3, 2016
@Serhy: Isn't that backwards? I would think that by doing os.path first most other libraries would not have to change.
serhiy-storchaka commentedon Jun 3, 2016
I think that if some high-level function uses os.path, it likely should convert Path argument to str either because the path should be saved as a string, or for performance if multiple os.path functions are called with the same argument. Note, that some os.path functions will implicitly support path objects if the posix module support it.
Let first find the functions that need path objects support in os.path.
ethanfurman commentedon Jun 3, 2016
The expected scenario, and the purpose of os.fspath(), is to enable high-level libraries to not know or care if they receive a pathlib object or a string.
In other words, they already have os.path.join() and os.path.split() calls, and currently break noisily if a pathlib.Path is passed in; by enhancing os.path to accept a pathlib.Path object that high-level library can start working with pathlib.Path objects without changing a thing, which means the user of that library can use pathlib.Path painlessly.
Unless I have seriously misunderstood something, os.path will be changed to work with __fspath__ objects.
brettcannon commentedon Jun 3, 2016
os.path will be updated to work with __fspath__() as specified by Guido as part of the conversation for PEP-519 (IOW listing os.path as being updated in PEP-519 is not an accident).
brettcannon commentedon Aug 5, 2016
I added support for ntpath as part of issue bpo-27524.