[Python-ideas] PEP 428 - object-oriented filesystem paths

[Joshua Landau]

On 8 October 2012 20:14, Stefan Krah <stefan at bytereef.org> wrote:

> Guido van Rossum <guido at python.org> wrote:
> > 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*.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121008/55495489/attachment.html>