[Python-Dev] Path inherits from string (original) (raw)

BJörn Lindqvist bjourne at gmail.com
Sat Jan 28 01:29:39 CET 2006

[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 PyObjectUnicode() 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

More information about the Python-Dev mailing list