[Python-Dev] The path module PEP

Ian Bicking ianb at colorstudy.com
Thu Jan 26 05:30:40 CET 2006


Barry Warsaw wrote:
> On Wed, 2006-01-25 at 18:10 -0600, Ian Bicking wrote:
> 
> 
>>Paths are strings, that's in the PEP.
>>
>>As an aside, I think it should be specified what (if any) string methods 
>>won't be inherited by Path (or will be specifically disabled by making 
>>them throw some exception).  I think .join() and __iter__ at least 
>>should be disabled.
> 
> 
> Whenever I see derived classes deliberately disabling base class
> methods, I see red flags that something in the design of the hierarchy
> isn't right.

IMHO the hierarchy problem is a misdesign of strings; iterating over 
strings is usually a bug, not a deliberately used feature.  And it's a 
particularly annoying bug, leading to weird results.

In this case a Path is not a container for characters.  Strings aren't 
containers for characters either -- apparently they are containers for 
smaller strings, which in turn contain themselves.  Paths might be seen 
as a container for other subpaths, but I think everyone agrees this is 
too ambigous and implicit.  So there's nothing sensible that __iter__ 
can do, and having it do something not sensible (just to fill it in with 
something) does not seem very Pythonic.

join is also a funny method that most people wouldn't expect on strings 
anyway.  But putting that aside, the real issue I see is that it is a 
miscognate for os.path.join, to which it has no relation.  And I can't 
possibly imagine what you'd use it for in the context of a path.


-- 
Ian Bicking  |  ianb at colorstudy.com  |  http://blog.ianbicking.org


More information about the Python-Dev mailing list