[Python-Dev] [Python-3000] Unipath package

Mike Orr sluggoster at gmail.com
Sun Jan 28 23:18:51 CET 2007


On 1/28/07, Larry Hastings <larry at hastings.org> wrote:
>  I dropped the Cc: of Python-3000, because I don't think this discussion
> falls under that mailing list's charter.  As I understand it, the
> Python-3000 mailing list is for discussing the details of implementing
> Python 3000.  "Stuff I'd like to see in Python 3000" doesn't go there, it
> goes to "Python-Ideas".

python-ideas didn't exist when this thread was started. :)  I was just
giving a status report on existing issues we'd discussed on
python-3000.  You're right that any future work in this area will
probably involve python-ideas.  I'm waiting for Unipath to get some
use before re-raising the question of what direction we want the
stdlib to go.  I also support the other proposal to move some
functions from os.path/shutil to os, which is being worked on.

>  One part of your message caught my eye:
>
>  Passing an absolute foreign path is an error, because there's no sane way
> to interpret "C:\\" on Posix or "/" on Windows.
>  There is in fact a very sane way to interpret "/" on Windows: the root
> directory of the "current" drive.  It's equivalent to "\".

That's one way to do it, but whether Unipath should presume this is
what the programmer wants is another issue.  One can make an argument
either way.  I found it appealing to categorically refuse to translate
absolute paths to a foreign system, and force the user to make the
path relative and explicitly attach it to a new root (or
subdirectory).  "Explicit is better than implicit", as the Python
mantra goes.  If this turns out to be a hassle for programmers, we can
always be more lenient later.

> I guess it isn't
> widely known, but nearly all Windows APIs are agnostic about whether you use
> "\" or "/" as a directory separator.  (The only exceptions I recall are the
> common dialog open / save file functions.)  I'm a Windows programmer, and I
> frequently use "/".

I've heard contradictory things about this.  Some people say just use
"/" and be happy; others say you get into trouble sometimes because
it's not the Windows kernel that does this but the application or
function, so some applications support it and some don't.  In
particular I've heard that "/" on the command line is handled by the
application, which may impose the DOS semantics ("option flag") rather
than "directory separator".

>  The fact that you don't understand this about how Windows paths work makes
> me nervous about your path library.  For instance, did you correctly support
> local paths on explicit drives (e.g. "d:../foo")?

I did use Windows regularly until 1998.  I do remember drive-relative
paths.  My question is, do people seriously use them anymore?  In a
Python program?  Specifying a drive-relative path or chdir'ing to it
should work.  The one thing Unipath does is consider it absolute:
isabsolute() returns True, and .components() and .split_root() return
"d:" as the root of the filesystem -- which it is.  Joining the
components produces the original path, which Windows should correctly
interpret.  So I don't see the harm as treating it as absolute in my
model.  Maybe it does create some hardship for Windows users, and
maybe I'll have to consider.  But drive-relative paths are really an
intermediate level between absolute and relative, and the model has no
place for the relative drive specification.  E.g.,

    Path("../foo").components()  =>  ["", "..", "foo"]
    Path("C:\\foo").components()  =>  ["C:\\", "foo"]
    Path("C:../foo").components() => ["C:", "..", "foo"]

Strictly speaking, the last path is relative so the first element
should be "".  But that would leave no place for the "C:" specifier,
which would either belongs at index 0.5 or in a special attribute.
Accommodating either would require changing the entire model to
accommodate an obscure Windows-only feature, even though the model
works quite well otherwise.

It may be that Unipath just isn't suitable for manipulating Windows
drive-relative paths, and making it do so would would mess up Unipath
too much.  The former is for Windows users to decide; the latter is
for me to decide based on their input.

I have also dropped .drive, .unc, .splitdrive(), and .splitunc().  I
think .split_root() is robust enough for what people want to do.  But
I may be wrong.  If there's necessity for those methods/properties
I'll add them, but I don't want to add a bunch of legacy methods that
will rarely be called.

-- 
Mike Orr <sluggoster at gmail.com>


More information about the Python-Dev mailing list