Hallvard B Furuseth (nospam nospam)
h.b.furuseth at usit.uio.no
Fri Jul 18 15:21:31 CEST 2003
Ian Bicking wrote:
>On Mon, 2003-07-14 at 06:44, Hallvard B Furuseth wrote:
>>Ian Bicking wrote:
>>> 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
Because we disagree about whether or not anyone will use it:-)
>> 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.
FIne by me. I wasn't thinking of what the internals would look like at
>>> 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.
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.
More information about the Python-list