path module

[Ian Bicking]

On Mon, 2003-07-14 at 06:44, Hallvard B Furuseth wrote:
> Ian Bicking wrote:
> >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.  (...)
> 
> > 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.
> 
> 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.

Since *no one* will ever use joindir or joinfile, why would it be
helpful?  Modern systems just don't make that distinction, and people
aren't going to make that distinction in their code.

> Also, you may need some special handling of 'device:' on Windows.

Yes, and the network portion as well (\\server\...).  However, it would
still be handled textually.  I.e., path(r'\\server') would happen to
create this network path, and path(r'\something_else') wouldn't.  The
Windows implementation of path would presumably have an attribute to get
at "server" (.unc or something), while you'd get an AttributeError on
Posix systems.

> > 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.
> 
> I dunno.  People have already mentioned coming systems where versions
> will be availbale.

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.

  Ian