[Python-Dev] PEP 8 updates/clarifications, function/method style

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