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. While I understand that you want to be able to use Path instances anywhere a string is currently used, I'm not sure that deriving from str is the right thing. Maybe deriving from basestring would be better, but even then I'm not sure. Is it possible that we don't need Path objects to interchangeable with strings, but just that we can get away with expanding a few critical functions (such as open())? > I think the use of underscores or squished words isn't as bit a deal as > the case of modules. It's often rather ambiguous what a "word" really > is. At least in English word combinations slowly and ambiguously float > towards being combined. So abspath and abs_path both feel sufficiently > inside the scope of PEP 8 that precedence is worth maintaining. > rfc822's getallmatchingheaders method was going too far, but a little > squishing doesn't bother me, if it is consistent (and it's actually > easier to be consistent about squishing than underscores). For something like "abspath" which is really an abbreviation + word, I suppose squishing them isn't so bad. The alternative is absolute_path() which is certainly more readable if a bit of a pain to write. It's a trade-off that should be made for practical purposes. I've definitely come to prefer spellings like is_absolute over isabsolute, and in general dislike squish words. -Barry
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
