[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 ________________________________________________________________________ -- http://mail.python.org/mailman/listinfo/python-list