[Python-Dev] The path module PEP (original) (raw)

Barry Warsaw barry at python.org
Thu Jan 26 05:17:43 CET 2006

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 abspath 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

-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/python-dev/attachments/20060125/00fb0c1a/attachment.pgp

More information about the Python-Dev mailing list