path module

Re: path module

Ian Bicking wrote:[color=blue]
> I think Jason Orendorff's path module is really nice:
> http://www.jorendorff.com/articles/python/path/[/color]

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

Van

Re: path module

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;v ersion

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.informa tik.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.

--
Hallvard

Re: path module


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;v ersion

Hallvard> where most components were optional.

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

device:[dir.dir.dir]file.ext;versio n

Skip

Re: path module

Ian Bicking wrote:[color=blue]
>On Mon, 2003-07-14 at 06:44, Hallvard B Furuseth wrote:[color=green]
>>Ian Bicking wrote:[color=darkred]
>>> Interesting, but I think a bad idea. (...) If someone was using VMS
>>> paths, I would assume they would subclass path for that OS, adding the
>>> portions that applied.[/color]
>>
>> It would be pointless to include _data structures_ for components that
>> are not supported on any system Python is ported to, but for subclassing
>> to make sense, some of the _interface_ would have to be in place. Like
>> the possibility of usin path.joindir() vs. path.joinfile() or something
>> depending on whether the result should be a file or directory path. And
>> just path.join() for people who don't care. Assuming there will be a
>> join method, of course.[/color]
>
> Since *no one* will ever use joindir or joinfile, why would it be
> helpful?[/color]

Because we disagree about whether or not anyone will use it:-)
[color=blue][color=green]
>> Also, you may need some special handling of 'device:' on Windows.[/color]
>
> Yes, and the network portion as well (\\server\...). However, it would
> still be handled textually.[/color]

FIne by me. I wasn't thinking of what the internals would look like at
all.
[color=blue][color=green][color=darkred]
>>> 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.[/color]
>>
>> I dunno. People have already mentioned coming systems where versions
>> will be availbale.[/color]
>
> 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.[/color]

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.

--
Hallvard