[Python-ideas] PEP 428: poll about the joining syntax
massimo.dipierro at gmail.com
Mon Oct 8 22:00:06 CEST 2012
p + q : +1
p / q : -1
Looks like I am a minority. :-(
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 | ncoghlan at gmail.com | Brisbane, Australia
> Python-ideas mailing list
> Python-ideas at python.org
More information about the Python-ideas