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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4