[Python-Dev] PEP 8 updates/clarifications, function/method style (original) (raw)

Michael Chermside mcherm at mcherm.com
Wed Dec 14 20:35:49 CET 2005

Guido writes:

Actually this (function, method and ivar names) is such a contentious issue that I think the style guide should explicitly allow all two/three styles and recommend to be consistent within a class, module or package.

Hurray! Now I can go back to using capWords for functions, methods, and variables!

Guido writes:

Too late. I don't think the diversity is all that distracting.

I disagree. One of the things that Java got very much right was to specify, from the very beginning, what the preferred conventions are for naming conventions. (Packages in lowercase, Classes in CapWords, methods and variables in lowerCapWords, constants optionally in ALL_CAPS. Abbrevs avoided, acronyms have all letters capitalized, eg: SimpleHTTPServer.)

The conventions are nearly universally followed, and as a result in java I always know how to spell things. I never have to remember whether it's myDict.hasKey() and myDict.popitem() or myDict.has_key() and myDict.popItem(). Haskell goes too far -- they REQUIRE a certain convention as part of the language... this prevents breaking the rules on purpose (eg: wrapping a library from another language, or using an object with attributes to represent an XML node with child nodes).

Of course, a really good IDE might make this irrelevent by popping up the correct option as I type... but the IDEs I use for Python don't even know the types of my variables, so they don't do this for me.

Anyhow... I don't think we can change it now, but I do believe that the lack of such conventions is a bit distracting. (Not enough to make me prefer Java, of course!)

-- Michael Chermside

More information about the Python-Dev mailing list