[Python-Dev] Path PEP: some comments (original) (raw)

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