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

[Massimo DiPierro]

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 at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas