[Python-Dev] Path PEP: some comments
Phillip J. Eby
pje at telecommunity.com
Sat Feb 4 22:08:42 CET 2006
At 08:35 PM 2/4/2006 +0100, Giovanni Bajo wrote:
>- ctime() is documented to be unportable: it has different semantics on UNIX
>and Windows. I believe the class should abstract from these details.
Note that this is the opposite of normal Python policy: Python does not
attempt to create cross-platform abstractions, but instead chooses to
expose platform differences. The Path class shouldn't abstract this any
more than the original *path modules do.
> One
>solution is to rip it off and forget about it. Another is to provide two
>different functions which have a fixed semantic (and possibly available only
>a subset of the operating systems / file systems).
Keep in mind that to properly replace os.path, each of the various *path
modules will need their own Path variant to support foreign path
manipulation. For example, one can use posixpath.join() right now on
Windows to manipulate Posix paths, and ntpath.join() to do the reverse on
Unix. So there is already going to have to be a Path class for each os
anyway - and they will all need to be simultaneously usable.
Note that this is a big difference from the Path implementation currently
in circulation, which is limited to processing the native OS's paths. The
PEP also currently doesn't address this point at all; it should probably
mention that each of the posixpath, ntpath, macpath, etc. modules will each
need to include a Path implementation. Whether this should be made
available as os.Path or os.path.Path is the only open question; the latter
of course would be automatic by simply adding a Path implementation to each
of the *path modules.
More information about the Python-Dev
mailing list