[path-PEP] Path inherits from basestring again

[Tony Meyer]

> I, herewith, claim to have used it in the past.
> 
> But I am indifferent as to if its needed, it just looks natural to me.

So far there seem to have been a few +0s, but no +1s...

> What I use quite often is::
> 
>    path(__file__).dirname() / "somesiblingfileiknowisthere"
> 
> you do not have to think about trailing slashes or absolute vs. 
> relative. and its much better than::
> 
>    from os.path import *
>    join(dirname(__file__), "somesiblingfileiknowisthere")

In what way is this "much better"?  To me, this is much worse, because it is
not at all clear what it means (a *huge* benefit of using Python is that you
can read the code just like pseudocode).  It is immediately clear from the
second example that you are joining two things together.  The first one, you
could be joining, or you could be dividing.  Compare:

    my_directory_string_object / "somesiblingfileiknowisthere"

and

    my_directory_path_object / "somesiblingfileiknowisthere"

These look the same, but one will raise a TypeError, and the other will
result in a joined Path.  How do I tell which is which when reading source,
without explicitly saying that I'm using a Path object?

> __div__ is actually very convenient to "build" / "a" / "very" 
> / "very" / "long" / "path"

Would you really choose this:

    p = Path() / "build" / "a" / "very" / "very" / "long" / "path"

Over this:

    p = Path(os.path.join("build", "a", "very", "very", "long", "path"))

?  A saving of six characters, and the second one is a lot clearer.  If
there was a os.path.joinPath (or whatever name) function that returned a
Path object rather than a string, then you'd get:

    p = joinPath("build", "a", "very", "very", "long", "path")

Which is better (clearer, more concise) than either of the others, IMO.

=Tony.Meyer