[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