[path-PEP] Path inherits from basestring again

[Tim Golden]

[Tony Meyer]

| 
| [Tim Golden]
| > Well, I actually had some correspondence with Jason on this 
| > very subject a year or so ago:
| [...]
| > Obviously, I don't know how much weight Jason's original 
| > ideas have on the prepped-for-syslib module, but it does 
| > support what other people have been saying: that the Path 
| > should behave like a string where a string is expected.
| 
| Was that the whole email?  It certainly adds weight to '+' 
| having the normal
| string behaviour, but it didn't really say anything about why 
| '/' should be
| a shortcut for join.  Do you know if Jason had any reasoning 
| for this other
| than laziness <wink>?
| 
| =Tony.Meyer

Well, he did add the following paragraph:

<email>
For example:  I haven't tried it, but I don't think the most obvious
two-line fix will necessarily work.  If you change __add__ to call
os.path.join(), you'll likely get infinite recursion, because os.path.join()
probably uses + to do its work.  Of course this is pretty easy to work
around; call it three lines.
</email>

which might explain why he *didn't* use __add__ but doesn't explain
whey he *did* use __div__. (There was more to the original email
but that was more to do with some wild-eyed ideas I'd had about
adding methods for file-locking and share-mounting to the path
object).

FWIW, my own feeling is that / is an awkward fit and relies for
its ease-of-reading on the -- admittedly common but not universal -- 
use of that symbol as a path separator. I don't feel terribly strongly
about it, but I don't tend to use it in my own code.

TJG

________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________