path module

[Ian Bicking]

I think Jason Orendorff's path module is really nice:
http://www.jorendorff.com/articles/python/path/

Beats the hell out of os.path, which is an ugly thing indeed. The OO
interface means you could use the interface nicely to implement other
things, like URLs. The problem? It's just some module. The various os
functions (of which path replaces quite a few) have become idiomatic to
me, and I'm sure others as well. I find myself reluctant to use it in
code that's not essentially private, because it's changing something
small and seemingly trivial, and people won't be familiar with it.

The solution? It should be a builtin! Or, if not a builtin, included
in the os module. But I actually like the idea of it being a builtin --
if open is a builtin, path stands right up there too. It would get rid
of 90% of the use of the os module.

Thoughts? Reactions?

Ian

 

[Van Gale]

I think Jason Orendorff's path module is really nice:
http://www.jorendorff.com/articles/python/path/

I love it and have been using it in a few personal projects. My only
gripe is its monolithic nature

Van

 

[Hallvard B Furuseth]

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.

 

[Skip Montanaro]

Hallvard> It's a long time since I used anything like that, but I think
Hallvard> Tops-20 filename paths looked like this:

Hallvard> device:<dir.dir.dir>file.ext;version

Hallvard> where most components were optional.

which is (not too surprisingly) very similar to VMS:

device:[dir.dir.dir]file.ext;version

Skip

 

[Hallvard B Furuseth]

Since *no one* will ever use joindir or joinfile, why would it be
helpful?

Because we disagree about whether or not anyone will use it

Yes, and the network portion as well (\\server\...). However, it would
still be handled textually.

FIne by me. I wasn't thinking of what the internals would look like at
all.

But we have no idea what it will look like, or how it may be represented
in a filename (if at all!) -- so implementing something based on that
would be a little optimistic. You're likely to create an interface that
won't make sense. Better to leave it unspecified until there's an
actual system you want to support, at which point the interface will
seem much clearer. Predictive design is a very bad idea.

Actually I disagree here. The danger of designing to an existing system
is that another system may come along where the versioning doesn't fit
our design. I think it's a good idea to design it - but not necessaril
implement it - before we see how it works on a real system. Then the
real system comes will either prove that we did good enough, or that we
didn't. In the latter case, it may be better to leave it out anyway.