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

Ian Bicking ianb at colorstudy.com
Thu Jan 26 01:10:27 CET 2006

Tony Meyer wrote:

[Ian Bicking]

If it were possible to use .join() for joining paths, I think I wouldn't mind so much. But reusing a string method for something very different seems like a bad idea. So we're left with .joinpath (). Still better than os.path.join() I guess, but only a little. I guess that's why I'm +1 on /. Why does reusing a string method for something very different seem like a bad idea, but reusing a mathematical operator for something very different seem like a good idea? Path's aren't strings, so join () seems the logical choice. (There are also alternatives to "joinpath" if the name is the thing: add(), for example).

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.

Precedence in naming means something, and in this case all the names have existed for a very long time (as long as Python?) PEP 8 encourages following naming precedence. While I don't see a need to match every existing function with a method, to the degree they do match I see no reason why we shouldn't keep the names. And I see reasons why the names shouldn't be changed.

PEP 8 encourages following naming precedence within a module, doesn't it? Guido has said that he'd like to have the standard library tidied up, at least somewhat (e.g. StringIO.StringIO -> stringio.StringIO) for Python 3000. It would make it less painful if new additions already followed the plan.

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).

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

More information about the Python-Dev mailing list