path module

Ian Bicking ianb at colorstudy.com
Tue Jul 8 14:01:31 EDT 2003


On Tue, 2003-07-08 at 09:52, Hallvard B Furuseth wrote:
> If there is going to be a New Wonderful Path module, I suggest you give
> some thought to paths on systems that don't fit the simple Unix/Windows
> path model.  A path to a filename may e.g. looks different from a path
> to a directory.  It's a long time since I used anything like that, but I
> think Tops-20 filename paths looked like this:
> 
>     device:<dir.dir.dir>file.ext;version
> 
> where most components were optional.  The device: part could also be a
> 'logical name' (basically an alias) for a directory or device, I don't
> remember if it could alias a file name too.
> 
> The Common Lisp pathname type might be worth looking into,
> <http://www.iti.informatik.tu-darmstadt.de/cl-hyperspec/Body/sec_19-2.html>
> They have done a lot of work to try to get it right, and from what
> I hear they did a good job.

Interesting, but I think a bad idea.  I don't believe Python has been
ported to Tops-20, and I'm not sure if there's a viable VMS port
either.  Most filesystems don't have the complexity that the Lisp
pathname encapsulates.  If someone was using VMS paths, I would assume
they would subclass path for that OS, adding the portions that applied. 
I think it's unreasonable to expect people programming on normal
platforms to pay attention to components like version, so even including
it in a structured manner is asking for trouble.

On some level such filesystems would probably be supportable, though. 
You just wouldn't adapt the filesystem's native structure, though
presumably your os module would know how to parse such a path and emit
such a path.  But like you can use / instead of \ for filenames on
Windows, I would expect / to work on most other filesystems as well.

  Ian







More information about the Python-list mailing list