[Python-Dev] Path inherits from string

[BJörn Lindqvist]

[M.-A. Lemburg]
> I don't see why this is critical for the success of the Path
> object. I agree with Thomas that interfaces should be made
> compatible to Path object.

See the steps I mentioned. Unless step #1 is completed there is no way
to make the following code work:

    open(Path("foobar"))

Well, there is one alternative which is:

    open(Path("foobar").tostring())

And that is a Java-esque workaraound that I think noone would be happy
with.

> Why not ? We've added Unicode support to at least some
> file I/O APIs - adding support for instances which
> support the string interface shouldn't be all that
> difficult :-)

> BTW, if you're fine with this API:

> class File:
>    def __unicode__(self):
>        return u"test.txt"

> then the required change is minimal: we'd just need to
> use PyObject_Unicode() in getargs.c:837 and you should
> be set.

Alright! If that is true then maybe step #1 isn't as hard as I
thought. First problem is the "string interface." What exactly is the
string interface? It needs to be specified. I would have guessed that
it was equal to the stuff in the builtin str class.. :) Then you need
to modify Python's C code so that it accepts all objects implementing
the string interface. That may not be a trivial task [1]. Also don't
forget that Path probably also should work with:

        isinstance(Path('.'), basestring)

Because one of the big selling points of Path is that it acts as a
drop-in replacement for strings [2]. And you don't want to mess with
the current canonical way of testing if an object implements the
"string interface." But you aren't supposed to subclass basestring
[3].

All I'm saying is that I don't have the technical knowledge required
to modify Python to make Path work without subclassing string. If you,
or someone else, do then pretty please with sugar on top make a patch
so that Path doesn't have to subclass string.

Then you could have a much more pure Path without the "dead"
methods. But even then, one could argue that Jason Orendorffs original
Path module is still more practical (atleast for compatibility
reasons).

    def save_data(somedir, fpath, data):
        open(somedir + "/" + fpath.lower(), "w").write(data)

The above code isn't going to work unless fpath is a string (or an
object that inherits from string).  It isn't good code, but it isn't
extremely uncommon either.

1 http://mail.python.org/pipermail/python-dev/2006-January/059780.html
2 http://mail.python.org/pipermail/python-list/2005-July/291213.html
3 http://mail.python.org/pipermail/python-dev/2006-January/059782.html


--
mvh Björn