Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > path module

Reply
Thread Tools

path module

 
 
Ian Bicking
Guest
Posts: n/a
 
      07-08-2003
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



 
Reply With Quote
 
 
 
 
Van Gale
Guest
Posts: n/a
 
      07-08-2003
Ian Bicking wrote:
> 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

 
Reply With Quote
 
 
 
 
Hallvard B Furuseth
Guest
Posts: n/a
 
      07-08-2003
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.

--
Hallvard
 
Reply With Quote
 
Skip Montanaro
Guest
Posts: n/a
 
      07-08-2003

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

 
Reply With Quote
 
Hallvard B Furuseth
Guest
Posts: n/a
 
      07-18-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
> helpful?


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
all.

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

--
Hallvard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: module docstring, documentation,anything? please note is the module type/object NOT some module Maric Michaud Python 0 06-24-2006 12:42 PM
Path as a dictionary tree key? (was Re: PEP on path module forstandard library) Ron Adam Python 3 08-02-2005 04:27 AM
Server.MapPath() croaking with "failed to map path", but path is legal awbacker@gmail.com ASP .Net 0 05-12-2005 10:50 PM
Bizzare: Invalid path to Access mdb, path is good Keith-Earl ASP .Net 1 05-03-2004 03:25 PM
Tomcat returning 404 error when using additional path (/servlet/myServlet/extra/path/info) Mupota Muchelemba Java 1 02-04-2004 12:43 AM



Advertisments