path module

Discussion in 'Python' started by Ian Bicking, Jul 8, 2003.

  1. Ian Bicking

    Ian Bicking Guest

    I think Jason Orendorff's path module is really nice:

    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 Bicking, Jul 8, 2003
    1. Advertisements

  2. Ian Bicking

    Van Gale Guest

    Van Gale, Jul 8, 2003
    1. Advertisements

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


    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,
    They have done a lot of work to try to get it right, and from what
    I hear they did a good job.

    Hallvard B Furuseth, Jul 8, 2003
  4. 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:


    Skip Montanaro, Jul 8, 2003
  5. 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

    >>> 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 B Furuseth, Jul 18, 2003
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Keith-Earl
    Peter O'Reilly
    May 3, 2004
  2. Replies:
  3. Mupota Muchelemba
    Tony Morris
    Feb 4, 2004
  4. Matt
    Jul 8, 2004
  5. James
    Andrew Thompson
    Dec 7, 2004
  6. Replies:
  7. Ron Adam
    Ron Adam
    Aug 2, 2005
  8. Maric Michaud
    Maric Michaud
    Jun 24, 2006