[Python-ideas] PEP 428 - object-oriented filesystem paths
solipsis at pitrou.net
Sat Oct 6 14:06:52 CEST 2012
On Sat, 06 Oct 2012 17:39:13 +0900
"Stephen J. Turnbull"
<turnbull at sk.tsukuba.ac.jp> wrote:
> I wonder if there is a need to distinguish between a path naming a
> directory as a collection, and as a file itself? Or can/should this
> be implicit (wash my mouth out with soap!) in the operation using the
I don't think there's a need to distinguish. Trying to
access /etc/passwd/somefile will simply raise an error on I/O.
> > Someone else proposed overloading '+', which would be confusing
> > since we need to be able to combine paths and regular strings, for
> > ease of use.
> Is it really that obnoxious to write "p + Path('bar')" (where p is a
> What about the case "'bar' + p"? Since Python isn't C, you can't
> express that as "'bar'[p]"!
The issue I envision is if you write `p + "bar"`, thinking p is a Path,
and p is actually a str object. It won't raise, but give you the wrong
> > Both '/' and '\\' are accepted as path separators under Windows. Under
> > Unix, '\\' is a regular character:
> That's outright ugly, especially from the "collections" point of view
> (foo/bar/xyzzy is not a member of foo). If you want something that
> doesn't suffer from the bogosities of os.path, this kind of platform-
> dependence should be avoided, I think.
Well, you do want to be able to convert str paths to Path objects
without handling path separator conversion by hand. It's a matter of
> > > Also, there is no good terminology in current use here. The only
> > > concrete thing I can suggest is that "root" would be better used as
> > > the term for what you're calling "anchor" as Windows users would
> > > expect the root of "C:\foo\bar\baz" to be "C:\".
> > But then the root of "C:foo" would be "C:", which sounds wrong:
> > "C:" isn't a root at all.
> Why not interpret the root of "C:foo" to be None? The Windows user
> can still get "C:" as the drive, and I don't think that will be
> surprising to them.
That's a possibility indeed. I'd like to have feedback from more
Windows users about your suggestion:
which would also give the following for UNC paths:
> I wonder if "mount_point" is sufficiently general to include the roots
> of real local file systems, remote file systems, Windows drives, and
> pseudo file systems? An obvious problem is that Windows users would
> not find that terminology natural.
Another is that finding mount points is I/O, while finding the root is
a purely lexical operation.
Software development and contracting: http://pro.pitrou.net
More information about the Python-ideas