[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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com