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

Steve Holden steve at holdenweb.com
Thu Jan 26 20:55:08 CET 2006

Ian Bicking wrote:

Fredrik Lundh wrote:

However, I might be wrong because according to [1] it should work. And having to wrap the Path object in str() (open(str(somepath))) each and every time the called function expects a string is not a practical solution.

in Python, the usual way to access an attribute of an object is to access the attribute; e.g. f = open(p.name) You mean "f = open(Path(p).name)", because it is likely that people will also have to accept strings for the nearterm (and probably longeterm) future. And the error message without will be inscrutable (and will still be inscrutable in many cases when you try to access other methods, sadly). And currently .name is taken for something else in the API. And the string path is not really an attribute because the string path is the object, it is not part of the object. OTOH, str(path) will break unicode filenames. And unicode() breaks anything that simply desires to pass data through without effecting its encoding. An open method on paths simplifies many of these issues, but doesn't do anything for passing a path to legacy code. Changing open() and all the functions that Path replaces (e.g., os.path.join) to accept Path objects may resolve issues with a substantial portion of code. But any code that does a typecheck on arguments will be broken -- which in the case of paths is quite common since many functions take both filename and file object arguments. Would it help to redefine file/open so they called an open() method on the argument were one defined, otherwise reverting to current behaviour?

That way we could just just define an open(self) method for path objects. I doubt performance is a huge issue here.

regards Steve

Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/

More information about the Python-Dev mailing list