Antoine Pitrou writes:
On Tue, 9 Oct 2012 00:45:41 +0530 Nick Coghlan firstname.lastname@example.org wrote:
On Tue, Oct 9, 2012 at 12:24 AM, Guido van Rossum email@example.com wrote:
I don't like any of those; I'd vote for another regular method, maybe p.pathjoin(q).
I don't *love* joinpath as a name, I just don't actively dislike it the way I do the four presented options (and it has the virtue of the path.py precedent).
How about one_path.to(other_path) ?
TOOWDTI, yes, but to me what it obviously does is
Path("/usr/local/bin").to(Path("/usr/bin")) => Path("../bin")
Ie, to me it's another spelling for .relative_to(), except that the operands have reversed. FWIW M€2% YMMV etc.
Some random thoughts follow. If you think that is out of keeping with the progress of this thread<wink/>, stop reading now.
I just don't think this problem (of convenient and object-oriented paths) is going to get solved. Basically what most of the people who are posting about this seem to want is a subclass of string that DWIMs. The problem is that "DWIM" varies substantially across programmers, and seems to be nondeterministic for some (me, for one). If path "objects" "should" behave like strings with specialized convenience methods, how can you improve on os.path? I haven't seen any answers to that, only "WIBNI Paths looked like strings representing paths?" And only piece by piece at that, no coherent overview of what Paths-like-str might look like from a space station.
If we're going to have an object-oriented path module, why can't it be object-oriented? Paths are sequences of path components. They are not sequences of characters. Sorry! Path components are strings (or subclasses thereof), but they have additional syntax (extensions, Windows devices, Windows remote paths). Maybe that, we can do something with!
Antoine says that Paths need to be immutable. Makes sense, but does that preclude having MutablePath? Then `mp[-1] += ".ext"` is a natural notation, no? How about `mp[-1] %= ".tex"; mp[-1] += .pdf"`? Then just
my_path = MutablePath(arg_path) mutate(my_path) return Path(my_path)
does the work safely.
As has been noted several times, all paths have syntax resembling URL syntax. Even the semantics are similar, except (of course you are in no way surprised by this) on Windows, where the syntactic role of "scheme" has semantics "device", and there is the issue of the different path separator. Maybe it would be reasonable to forget object-oriented Paths restricted to filesystems and use URLs when you want object-oriented behavior. Under the hood URL methods working with file URLs would be manipulating paths via os.path, perhaps.
I realize that this would impose an asymmetric burden on developers on Windows. On the other hand, these days who isn't familiar with URL syntax and passing familiar with its minor differences from file system path semantics? Perhaps the benefits of working with a well-defined object model would outweight the costs, at least when developing new code. In ordinary maintenance or major refactoring, the developer would have the option of continuing to use os.path or homebrew functions to manipulate paths.