[Python-ideas] PEP 428: poll about the joining syntax

[Stephen J. Turnbull]

Antoine Pitrou writes:
 > On Tue, 9 Oct 2012 00:45:41 +0530
 > Nick Coghlan <ncoghlan at gmail.com> wrote:
 > > On Tue, Oct 9, 2012 at 12:24 AM, Guido van Rossum <guido at python.org> 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).

+1

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

Steve