[Python-Dev] Path inherits from string

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