Thoughts on os.path? What happened to the idea of a new path object?
--Guido
---------- Forwarded message ----------
From: Talin <viri...@gmail.com>
Date: Wed, Jan 30, 2013 at 12:34 PM
Subject: Re: I was just thinking that os.path could use some love...
To: Guido van Rossum <gu...@python.org>
On Wed, Jan 30, 2013 at 11:33 AM, Guido van Rossum <gu...@python.org> wrote:
>
> Hmm... Mind if I just forward to python-dev? IIRC there's been some
> discussion about a newfangled path object, but I lost track of where
> the discussion went. (Or you can post there yourself. :-)
Sure - forward away. Is this the same as the path object idea that was
floated 5 years ago? I've yet to see any set of convenience methods
for paths that are so compelling as to be worth all of the time and
energy needed to update all of the various APIs which now expect paths
to be passed in as strings.
>
>
> On Wed, Jan 30, 2013 at 11:13 AM, Talin <viri...@gmail.com> wrote:
> > I just realized that os.path hasn't changed in a long time. Here's a couple
> > of ideas for additions:
> >
> > os.path.splitall(path) - splits all path components into a tuple - so for
> > example, 'this/is/a/path' turns into ('this', 'is', 'a', 'path'). If there's
> > a trailing slash, the last item in the tuple will be a zero-length string.
> > The main reason for having this in os.path is so that we can remain
> > separator-character-agnostic.
>
> Would it also return a leading empty string if the path starts with /?
> What about Windows C: or //host/ prefixes???
>
I would say that it should only split on directory separators, not any
other kind of delimiter, so that each component is a valid filesystem
identifier. Further, the operation should be reversible by calling
os.path.join(*dirnames). So it's a little more complex than just
string.split('/').
Part of the reason for wanting the splitall function is to implement
the common prefix function - you take all the paths, bust them into
tuples, look for the longest tuple prefix, and then join the result
back into a path. This means that
os.path.join(*os.path.splitall(path)) must reproduce the original path
exactly.
>
> > An alternative would be to add an optional 'maxsplits' parameter to
> > os.path.split. Default would be 1; 0 = unlimited. Main disadvantage would be
> > that no one would ever use values 2, 3, etc... but it would be more
> > compatible with other split apis.
> >
> > A version of os.path.commonprefix that always produces valid paths (and
> > works by path component, not character-by-character).
> >
> > I can probably think of others if I look at some other path manipulation
> > apis. llvm::sys::path has a bunch if I recall...
> >
> > --
> > -- Talin
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
--
-- Talin
--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
