[Python-ideas] PEP 428 - object-oriented filesystem paths

[Stephen J. Turnbull]

Antoine Pitrou writes:

 > >  > 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
 > > Path)?
 > > 
 > > 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
 > result.

No, my point is that for me prepending new segments is quite common,
though not as common as appending them.  The asymmetry of the bracket
operator means that there's no easy way to deal with that.

On the other hand, `p + Path('foo')` and `Path('foo') + p` (where p is
a Path, not a string) both seem reasonable to me.  It's true that one
could screw up as you suggest, but that requires *two* mistakes, first
thinking that p is a Path when it's a string, and then forgetting to
convert 'bar' to Path.  I don't think that's very likely if you don't
allow mixing strings and Paths without explicit conversion.

 > >  > 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
 > practicality.

Sorry, cut too much context.  I was referring to the use of
path['foo/bar'] where path['foo', 'bar'] will do.  Of course
overloading the constructor is an obvious thing to do.