[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