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

Gustavo J. A. M. Carneiro gjc at inescporto.pt
Thu Jan 26 01:30:58 CET 2006

On Wed, 2006-01-25 at 21:37 +0100, BJörn Lindqvist wrote:

Renaming methods because of PEP 8 (Gustavo, Ian, Jason)

I'm personally not keen on that. I like most of the names as they are. abspath(), joinpath(), realpath() and splitall() looks so much better than abspath(), joinpath(), realpath() and splitall() in my eyes. If someone like the underscores I'll add it to Open Issues.

Function Names 
  Function names should be lowercase, with words separated by underscores
  as necessary to improve readability.

  mixedCase is allowed only in contexts where that's already the
  prevailing style (e.g. threading.py), to retain backwards compatibility.

Method Names and Instance Variables

  Use the function naming rules: lowercase with words separated by
  underscores as necessary to improve readability.

It is very clear. Whether you agree with PEP 8 or not is not relevant to this discussion. Since this is a completely new module, it should be correctly named from the start. The "familiarity with os.path argument" is a very weak one, IMHO.

Plus, the names are full of redundancy. Why abspath(), joinpath(), realpath(), splitall()? Why not instead: absolute(), join(), real(), split() ? Remember that they are all methods of a Path class, you don't need to keep repeating 'path' all over the place[1].

On a slightly different subject, regarding path / path, I think it feels much more natural path + path. Path.join is really just a string concatenation, except that it adds a path separator in the middle if necessary, if I'm not mistaken.

Best regards.

[1] Yes, I'm the kind of guy who hates struct timeval having tv_sec and tv_usec field members instead of sec and usec.

-- Gustavo J. A. M. Carneiro <gjc at inescporto.pt> <gustavo at users.sourceforge.net> The universe is always one step beyond logic

More information about the Python-Dev mailing list