Path inherits from basestring again

[Jordan Rastrick]

Personally, I *like* the current distinction between + as a regular
string join, which gives the already much discussed benefit of allowing
paths to be dropped in seamlessly and painlessly anywhere strings are
currently used, and then having in addition the / operator for
"concatenate with a path separator." I think its intuitive, and the
option least likely to surprise someone encountering code that uses the
Path class for the first time - + works exactly like it always does,
and if they see a slash, which is an entirely new operator for
string-like objects, they'll be alerted to the fact they're getting
behaviour that differs from familiar string operators and methods.

Having + work differently when acting between a string and a path
versus a path and a path is in my mind a potential source of annoying
and subtle bugs, although hopefully they'd be rare in sensibly written
path-oriented code.

Sure, / means something completely different in the context of numbers.
So what? + and * are very different operators for numbers vs. strings,
but it doesn't generally trouble people too much; + has become pretty
widespread in programming conciousness as a string concatinator.

I don't think the argument that / and * are natural inverses holds much
water, either. In the context of sets in Python, - means set
difference, and +, its 'natural inverse', means nothing (in
mathematics, it typically means symmetric difference, which is
certainly not in any sense the inverse of -). This is all based on
arbitrary mathematical convention. The important point is that it
results in readable code for people who've dealt with sets before,
while trying to minimise the potential for surprises; not that it tries
to mirror the relationships between arithmetic operators, which I don't
think is an especially reasonable or normal thing to expect.

And I'm born and bred (unfortunately) on Windows machines, I do ALL my
Python programming in a Windows environment, so the "forward slash is
only an intuitive path seperator for POSIX hackers" argument doesn't
apply.

After all, anyone who's had any exposure to the internet can't be
entirely unfamiliar with the fact that forward slash can be used as a
path(-like) separator (please don't construe this as an attempt to
resurrect the "path should be used for URLs too" debate, though).
Ultimately, its just not different enough from backslash to be very
confusing (hear I'll put in a disclaimer, that I don't have enough
computing experience to know of any OS where neither type of slash is
used in paths.)

And thats my 14.5 cents :)

- Jordan Rastrick

Ron Adam wrote:
> Michael Hoffman wrote:
> > Ron Adam wrote:
> >
> >> In all current cases, (that I know of), of differing types, '+' raises
> >> an error.
> >
> >
> > Not quite:
> >
> >  >>> "hello " + u"world"
> > u'hello world'
> >  >>> 4.5 + 5
> > 9.5
> >
> >> Question:  Is a path object mutable?
> >
> >
> > No.
> >
> > This should answer the rest of your questions.
>
> Yes it does, thanks.
>
> In the case of numeric types, it's an addition and not a join.  I should
> have specified in 'all cases, (I know of), where '+' is used to join
> objects, but I thought that was clear from the context of the
> discussion.  I haven't needed to use unicode yet, so it didn't come to mind.
>
>
> Although it raises other questions...  ;-)
>
> Could a string prefix be used with paths as well?
>
>     path = p"C://somedir//somefile"
>
>
> Would that clash with the 'u' prefix?  Or would we need a 'p' and a 'up'
> prefix to differentiate the two?
>
> (Just a thought. I'm +0 on this, but this seems to be a new string type,
> and file operations are frequent and common.)
>
>
>
> You could have both behaviors with the '+'.
>
>      path_a + path_b  ->  join path_b to path_a using separator.
>
>      path + string ->  append string to path (no separator)
>
>      string + path ->  prepends string to path (no separator)
>
>
> This would be similar, (but not exactly like), how u'text'+'text' and
> 'text'+u'text' work.  They both return unicode strings given a standard
> string.  It would allow the following to work.
>
>
>      path = path('C:')+path('somedir')+path('somefile.txt')+'.zip'
>
>      ->>   'C://somedir//somefile.txt.zip'
>
>
>
> So I guess the question here is which of these is preferable with '+'?
>
> 1.  Strings act like paths when one is a path.  They will be joined with
> a separator.
>
> 2.  Paths are joined with separators *and* a string is prepended or
> postpended "as is" with no separator.
>
> 3.  All path objects (and strings) act like strings.  No separator is
> used when joining path objects with '+'.
>
>
> (Seems like #3 defeats the purpose of path a bit to me.)
> 
> 
> I'm +1 on #2 after thinking about it.
> 
> Cheers,
> Ron