> Personally I fear '+' much more -- to me, + can be used to add an
> extension without adding a new directory level. If we *have* to
> overload an operator, I'd prefer p/q over p[q] any day.
'^' or '@' are used for concatenation in some languages. At least accidental
confusion with xor is pretty unlikely.
On the basis that we want standard libraries to be non-contentious issues: is it not obvious that "+", "/" and "[]" cannot be the right choices as they're contentious?
I would argue that a lot of this argument is “pointless” because there is no right answer. For example, I prefer indexing out of the lot, but since a lot of people really dislike it I'm not going to bother vouching for it.
I think we should ague more along the lines of:
# Possibility for accidental validity if configdir is a string
configdir.join("myprogram")
# A bit long
# My personal objection is that one shouldn't have to state "path" in the name: it's not str.stringjoin()
configdir.joinpath("myprogram")
configdir.pathjoin("myprogram")
# There's argument here, but I don't find them intuitive or nice
configdir.subpath("mypogram")
configdir.superpath("mypogram")
# My favorites ('cause my opinion: so there)
configdir.child("myprogram") # Does sorta' imply IO
configdir.get("myprogram") # 'Cause it's short, but it does sorta' imply IO
configdir.goto("myprogam") # "GOTO IS BAD!! BOO!"
# What I'm surprised (but half-glad) hasn't been mentioned
configdir.cd("myprogam") # Not a link, just GMail's silly-ness
We already know the semantics for the function; now it's just a name.