[Python-ideas] PEP 428 - object-oriented filesystem paths
joshua.landau.ws at gmail.com
Mon Oct 8 21:41:30 CEST 2012
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
> 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
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
# A bit long
> # My personal objection is that one shouldn't have to state "path" in the
> name: it's not str.stringjoin()
# There's argument here, but I don't find them intuitive or nice
# 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
> 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...
More information about the Python-ideas