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.
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)
-- Nick Coghlan | email@example.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Pythonfirstname.lastname@example.org http://mail.python.org/mailman/listinfo/python-ideas