http://bugs.python.org/issue11344 evolved into a patch for 'splitpath', similar to splitall. Antoine's pathlib (PEP 428) is also mentioned at the end, which is probably what Guido is thinking of.
--David On Wed, 30 Jan 2013 13:26:08 -0800, Guido van Rossum <gu...@python.org> wrote: > 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/rdmurray%40bitdance.com _______________________________________________ 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