On Tue, Oct 9, 2012 at 12:24 AM, Guido van Rossum wrote:

I don't like any of those; I'd vote for another regular method, maybe p.pathjoin(q).

My own current preference is to take "p.joinpath(q)" straight from path.py (https://github.com/jaraco/path.py/blob/master/path.py#L236). My rationale for disliking all of the poll options (clarified during the previous discussions, so I can summarise it better now): "p[q]", "p + q", "p / q": A method API is desirable *anyway* (for better integration with all the tools that deal with callables in general), and no compelling justification has been provided for offering two ways to do it (mere brevity when writing doesn't cut it, when the result is something that is more cryptic when reading and learning). "p + q", "p.join(q)": passing strings where path objects are needed is expected to be a common error mode, especially for people just starting to use the new API. It is desirable that such errors produce an exception rather than silently producing an incorrect string. 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). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

p[q]: -1 p + q : +1 p / q : -1 p.join(q): -1 p.joinpath(q): -0 Looks like I am a minority. :-( Rationale: A directory structure with symbolic links is a graph. A path is an ordered set of links. A path can start anywhere in the graph and can end up anywhere. Links are represented by folder names. To me this means a natural representation of a Path as a list of strings which can be serialized in a OS-specific path. In fact today we all do, already: path.split(os.path.sep) and then manipulate the resulting list. Representing the Path with an object that has the same API as a list of strings (add, radd, append, insert, get item, get slice) and a few extra ones, will make it easier for new users to understand it and remember the APIs. I do not like p[q] and p/q because they fire the wrong neurons in my brain. p[q] picks an element in a set, p/q picks a subset of p. I also do not like p.join because p is not a string and it may be confusing. I am not opposed to q.joinpath(q) but it would require that users learn a new API. They cannot just guess it. they would have to look it up. That gives aways the main reason I use Python: it is intuitive. Moreover p.joinpath(q) seems to indicate that q is a path but q could be a string not a Path. Massimo On Oct 8, 2012, at 2:29 PM, Nick Coghlan wrote:

Reducing to numeric votes:

p[q]: -1 (confusing w.r.t to indexing/slicing, not convinced it is needed) p + q : -1 (confusing w.r.t to strings, not convinced it is needed) p / q : -0 (not convinced it is needed) p.join(q): -0 (confusing w.r.t strings) p.joinpath(q): +1 (avoids confusion, path.py precedent, need a method API anyway)

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

On Tue, 9 Oct 2012 00:45:41 +0530 Nick Coghlan wrote:

On Tue, Oct 9, 2012 at 12:24 AM, Guido van Rossum 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) ? Regards Antoine. -- Software development and contracting: http://pro.pitrou.net

...

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) ?

to() is just awesome. Short, rather easy to guess what it does, and easy to remember once you start using it. So now +1 on to() and &.

On 11/10/12 06:07, Antoine Pitrou wrote:

On Tue, 9 Oct 2012 00:45:41 +0530 Nick Coghlan wrote:

...

On Tue, Oct 9, 2012 at 12:24 AM, Guido van Rossum 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) ?

-1 "To" implies to me either: * one_path is mutated to become other_path; or * you supply the end points, and the method finds a path between them neither of which is remotely relevant. It certainly is not a synonym for add/join/combine/concat paths. Brevity is not more important than clarity. -- Steven

Antoine Pitrou writes:

On Tue, 9 Oct 2012 00:45:41 +0530 Nick Coghlan wrote:

...

On Tue, Oct 9, 2012 at 12:24 AM, Guido van Rossum 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

I'm a Python developer rather than a developer of Python, but I'd like to ask a question about this option (and implicitly vote against it, I suppose); if you specialize a method name, such as .pathjoin, aren't you implying that methods must be unambiguous even across types and classes? This seems negative. Even if .join is already used for strings, it also makes sense for this use case. Of course, the proposed syntactic sugar options (operator overloading) seems more pathological than either of the method-based options, so I suppose you could consider my votes as -1 to everything else, +.5 to .pathjoin, and +1 to .join. On Mon, Oct 8, 2012 at 2:54 PM, Guido van Rossum wrote:

I don't like any of those; I'd vote for another regular method, maybe p.pathjoin(q).

On Mon, Oct 8, 2012 at 11:47 AM, Antoine Pitrou wrote:

...

Hello,

Since there has been some controversy about the joining syntax used in PEP 428 (filesystem path objects), I would like to run an informal poll about it. Please answer with +1/+0/-0/-1 for each proposal:

- `p[q]` joins path q to path p - `p + q` joins path q to path p - `p / q` joins path q to path p - `p.join(q)` joins path q to path p

(you can include a rationale if you want, but don't forget to vote :-))

Thank you

Antoine.

-- Software development and contracting: http://pro.pitrou.net

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

Georg Brandl wrote:

Am 12.10.2012 14:45, schrieb Blake Hyde:

...

I'm a Python developer rather than a developer of Python, but I'd like to ask a question about this option (and implicitly vote against it, I suppose); if you specialize a method name, such as .pathjoin, aren't you implying that methods must be unambiguous even across types and classes? This seems negative. Even if .join is already used for strings, it also makes sense for this use case.

Of course different classes can have methods of the same name.

The issue here is that due to the similarity (and interchangeability) of path objects and strings it is likely that people get them mixed up every now and then, and if .join() works on both objects the failure mode (strange result from str.join when you expected path.join) is horribly confusing.

I don't understand the "horribly confusing" part. Sure, when I got them mixed up and ended up with a plain ol' string instead of a really cool Path it took a moment to figure out where I had made the error, but the traceback of "AttributeError: 'str' object has no attribute 'path'" left absolutely no room for confusion as to what the problem was. ~Ethan~

On Sat, 13 Oct 2012 04:26:44 +1000 Nick Coghlan wrote:

This is one I think Jason Orendorff's original path.py got right, which is why my current preference is "just copy path.py and use / and Path.joinpath".

This is my current preference too. I don't like joinpath(), but as long as there is an operator to do the same thing I don't care :-) Regards Antoine. -- Software development and contracting: http://pro.pitrou.net

Am 12.10.2012 18:27, schrieb Ethan Furman:

Georg Brandl wrote:

...

Am 12.10.2012 14:45, schrieb Blake Hyde:

...

I'm a Python developer rather than a developer of Python, but I'd like to ask a question about this option (and implicitly vote against it, I suppose); if you specialize a method name, such as .pathjoin, aren't you implying that methods must be unambiguous even across types and classes? This seems negative. Even if .join is already used for strings, it also makes sense for this use case.

Of course different classes can have methods of the same name.

The issue here is that due to the similarity (and interchangeability) of path objects and strings it is likely that people get them mixed up every now and then, and if .join() works on both objects the failure mode (strange result from str.join when you expected path.join) is horribly confusing.

I don't understand the "horribly confusing" part. Sure, when I got them mixed up and ended up with a plain ol' string instead of a really cool Path it took a moment to figure out where I had made the error, but the traceback of "AttributeError: 'str' object has no attribute 'path'" left absolutely no room for confusion as to what the problem was.

"no attribute 'path'"? Not sure where that exception comes from. This is what I meant:

...

...

p = Path('/usr') p.join('lib') Path('/usr/lib')

...

...

p = '/usr' p.join('lib') 'l/usri/usrb'

Georg

Joshua Landau wrote:

'.j/homeo/homes/homeh/homeu/homeacj/homeo/homes/homeh/homeu/homeaoj/homeo/homes/homeh/homeu/homeanj/homeo/homes/homeh/homeu/homeafj/homeo/homes/homeh/homeu/homeaij/homeo/homes/homeh/homeu/homeag'

Homeo, Homeo, wherefore path thou Homeo? -- Greg

Michele Lacchia wrote:

I wrote:

'.j/homeo/homes/homeh/homeu/homeacj/homeo/homes/homeh/homeu/homeaoj/homeo/homes/homeh/homeu/homeanj/homeo/homes/homeh/homeu/homeafj/homeo/homes/homeh/homeu/homeaij/homeo/homes/homeh/homeu/homeag'

Homeo, Homeo, wherefore path thou Homeo?

-- Greg

I just had to +1 on this one!! Congrats!

I also propose the term "julietted" to describe a string that has had this misfortune happen to it. -- Greg

On 08/10/2012 9:22pm, Paul Moore wrote:

p.joinpath(q) +1 I wish there was a better name, but I doubt one will appear :-(

I would go for p.add(q) which at least has the virtue of brevity. Richard

On 2012-10-08 23:17, Richard Oudkerk wrote:

On 08/10/2012 9:22pm, Paul Moore wrote:

...

p.joinpath(q) +1 I wish there was a better name, but I doubt one will appear :-(

I would go for

p.add(q)

I like the short 'add'. A small problem I see with 'add' (and with 'append') is that the outcome of adding (or appending) an absolute path is too surprising, unlike with the 'join' or 'joinpath' names. Also, How would we add an extension to a path (without turning it into a str first)? Will there be a method called addext() or addsuffix() as the .ext/.suffix property is immutable? The suggestions I saw in the thread so far targeted substituting the extension, not adding. Regarding '/', I would like to mention Scapy [1], the packet manipulation program. From its documentation: "The / operator has been used as a composition operator between two layers". The '/' feels natural to use with Scapy. An example from the docs:

Let’s say I want a broadcast MAC address, and IP payload to ketchup.com and to mayo.com, TTL value from 1 to 9, and an UDP payload:

...

...

...

Ether(dst="ff:ff:ff:ff:ff:ff")/IP(dst=["ketchup.com","mayo.com"],ttl=(1,9))/UDP()

Regards, TB [1] http://www.secdev.org/projects/scapy/

T.B. wrote:

A small problem I see with 'add' (and with 'append') is that the outcome of adding (or appending) an absolute path is too surprising, unlike with the 'join' or 'joinpath' names.

I don't think it's any less surprising with "join" -- when you join two things, you just as much expect both of them to be part of the result. There doesn't seem to be any concise term that encompasses all the nuances of the operation. Using an arbitrarily chosen operator would at least have the advantage of sidestepping the whole concern. Programmer 1: "Hey, what does ^ do on path objects?" Programmer 2: "It concatenates them with a path separator between, except when the second one is an absolute path, in which case it just returns the second one." Programmer 1: "That's so obscure. Why didn't they just define a concat_with_pathsep_or_second_if_absolute() method... oh, wait, I think I see..." -- Greg

On Tue, Oct 9, 2012 at 12:12 AM, Paul Moore wrote:

On 9 October 2012 00:19, Ryan D Hiebert wrote:

...

If we want a p.pathjoin method, it would make sense to me for it to work similar to urllib.parse.urljoin

The parallel with urljoin also suggests that pathjoin is a better name than joinpath. But note that I've seen both used in this thread - there is obviously some level of confusion possible.

pathjoin is strikes well, if we are already accustomed with the term 'urljoin'. Ryan - the protocols of those two joins will vary and should not be confused. Also pathjoin specifics would be listed in PEP 428. Thanks Senthil

On Tue, Oct 9, 2012 at 1:22 PM, INADA Naoki wrote:

-1 on `pathjoin`. `Path.pathjoin` is ugly. The `urljoin()` is OK because it is just a function.

Hmm, this is a *very* interesting point. *All* of the alternatives presented are mainly replacements for just doing this: Path(p, q) And if you want a partially applied version, that's just: prefix = functools.partial(Path, p) So perhaps the right answer for the initial API is: no method, no operator, just use the constructor? The counterargument is that this approach doesn't let "p" control the return type the way a method or operator does, though. It does suggest a whole new class of verbs though, like "make" or "build". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

I just consulted a thesaurus about synonyms for 'append', and it came up with 'affix' and 'adjoin'. -- Greg

On Tue, Oct 9, 2012 at 3:13 PM, Antoine Pitrou wrote:

...

It does suggest a whole new class of verbs though, like "make" or "build".

They are rather vague, though.

Agreed, but what os.path.join actually *does* is rather vague, since it is really "joins the path segments, starting with the last absolute path segment". I'm mostly playing Devil's Advocate here, but I thought it was a very good point that requesting a Path or PurePath directly is *always* going to be an option. And really, the only time you *need* a PurePath is when you want to construct a non-native path - for native paths you'll always be able to create it, some methods just won't work if it doesn't actually exist on the filesystem. Using Victor's more complicated example, compare: open(os.path.join(home, ".config", name + ".conf")) open(str(Path(home, ".config", name + ".conf"))) open(home.join(".config", name + ".conf"))) open(str(home / ".config" / name + ".conf")) Path(home, ".config", name + ".conf").open() home.join(".config", name + ".conf").open() (home / ".config" / name + ".conf").open() One note regarding the extra "str()" calls relative to something like path.py: we get to define the language, so we can get the benefits of implicit conversion without the many downsides by *defining a new conversion method*, such as __fspath__. That may provide an attractive alternative to offering methods that shadow builtin functions: open(Path(home, ".config", name + ".conf")) open(home.join(".config", name + ".conf")) open(home / ".config" / name + ".conf") "As easy to use as path.py, without the design compromises imposed by inheriting from str" is a worthwhile goal. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Tue, Oct 9, 2012 at 6:04 PM, Antoine Pitrou wrote:

That's a very good idea! Even better if there's a way to make it work as expected with openat support (for example by allowing __fspath__ to return a (dir_fd, filename) tuple).

The other thing I thought might be useful is to try to tie it into the new "opener" parameter for open somehow, On the other hand, that's getting further into full-blown filesystem emulation territory (http://packages.python.org/fs/). That may not be a bad thing, though - a proper filesystem abstraction might finally let us deal with encoding and case-sensitivity issues in a sane way, since they're filesystem dependent rather than platform dependent (e.g. opening FAT/FAT32 devices on *nix systems). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

`p[q]` 0 `p + q` +0.5 `p / q` +1 `p.join(q)` -1 `p.pathjoin(q)` -1 `p.pathjoin(q)` -1 `p.add(q)` +0.5 Joining/adding/appending paths is one of the most common ops. Please let's make it short, easy and obvious.

p + q +1 This is a familiar notation to any developer and its been used widely. Regards, Rohit. On Thu, Oct 11, 2012 at 8:04 AM, Eric Snow wrote:

On Oct 8, 2012 5:35 PM, "Eric Snow" wrote:

...

On Mon, Oct 8, 2012 at 12:47 PM, Antoine Pitrou

wrote:

...

...

- `p[q]` joins path q to path p -1 - `p + q` joins path q to path p -1 - `p / q` joins path q to path p -1 - `p.join(q)` joins path q to path p +1 (with a different name)

I've found Nick's argument against operators-from-day-1 to be convincing, as well as his argument against join() or any other name already provided by string/sequence APIs.

Changing my vote:

p[q] -1 p + q -1 p / q +0 p.pathjoin() +1

A method is essential, regardless of the color the bikeshed ends up. As far as operators go, / is the only option here that doesn't conflict with string/collection APIs. The alternative has an adverse impact on subclassing and on future design choices on the path API. This goes for the method name too.

-eric

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

On 09.10.12 05:42, Steven D'Aprano wrote:

p + ".ext" to add a suffix to the file name; an error if p is a directory.

Why? A directory can have a suffix. E.g. /etc/init.d.

Eric Snow writes:

...

...

`p.pathjoin(q)`

+1

It is very explicit and hard to get it wrong. +1 ...and it's not _that_ long a name.  This would be a provisional module, so we could try the name on for size <wink> or hide it behind an operator later.

Or, precisely, since it's provisional, we needn't *wait* before we provide an operator. Any stdlib module API can be augmented; what provisional modules allow in addition to that is to modify or remove existing APIs. So we can, say, enable Path.__truediv__ and wait for people to complain about it. By the way, it's not new to have dual operator / method APIs. For example set.union and set.__or__; list.extend and list.__iadd__; etc. Regards Antoine.

On Tue, Oct 9, 2012 at 3:32 PM, Terry Reedy wrote:

On 10/9/2012 9:30 AM, Eric Snow wrote:

...

On Oct 9, 2012 1:12 AM, "Senthil Kumaran" mailto:senthil@uthcode.com> wrote:

...

...

`p.pathjoin(q)`

+1

It is very explicit and hard to get it wrong.

or path.concat(otherpath)

-- Terry Jan Reedy

I like the [] syntax. ZODB works this way when the subpath name is not a valid Python identifier. a.b['c-d'] would be like a/b/c-d if ZODB was a filesystem. I like the + syntax. No one has suggested overloading the > operator? p1 > p2 > p3 The < operator would keep its normal use for sorting. ;-)

On 11/10/2012 04:24, Chris Jerdonek wrote:

Or how about path.slash(other_path)? :)

and path.backslash(other_path) for windows compaptibility ;-) Joachim