[Python-Dev] I was just thinking that os.path could use some love...
solipsis at pitrou.net
Thu Jan 31 09:55:21 CET 2013
Le Wed, 30 Jan 2013 13:26:08 -0800,
Guido van Rossum <guido at python.org> a écrit :
> Thoughts on os.path? What happened to the idea of a new path object?
I plan to launch another round of discussions following the changes in
> ---------- Forwarded message ----------
> From: Talin <viridia at 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 <guido at python.org>
> On Wed, Jan 30, 2013 at 11:33 AM, Guido van Rossum <guido at python.org>
> > 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 <viridia at 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
> 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
> > > 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
More information about the Python-Dev