[Python-Dev] Naming conventions in Py3K (original) (raw)

Brett Cannon brett at python.org
Fri Dec 30 07:33:49 CET 2005

On 12/29/05, Ka-Ping Yee <python-dev at zesty.ca> wrote:

In a fair number of cases, Python doesn't follow its own recommended naming conventions. Changing these things would break backward compatibility, so they are out of the question for Python 2.*, but it would be nice to keep these in mind for Python 3K.

Constants in all caps: NONE, TRUE, FALSE, ELLIPSIS Classes in initial-caps: Object, Int, Float, Str, Unicode, Set, List, Tuple, Dict, and lots of classes in the standard library, e.g. anydbm.error, csv.excel, imaplib.error, mutex.mutex... I know these probably look a little funny now to most of us,

Oh yeah. =)

as we're used to looking at today's Python (they even look a little funny to me) but i'm pretty convinced that consistency will be better in the long run.

Well, the problem is obviously requiring existing Python coders to have to re-educate themselves and the amount of code breakage. Luckily stuff like this should be changeable by some script that can try to convert 2.x code to 3.0 code.

I am fine with changing the built-in types, but changing the built-in singletons just looks really odd to me. So odd that I just don't want to see them changed. I mean when I think of constants, I think of a variable that references an object and that reference never changes. The built-ins you are referencing, though, are singletons: named objects that are not variables. So keeping their naming scheme as-is does not feel like a breaking of the rules to me since they are not treated the same (especially at the C level).

-Brett

More information about the Python-Dev mailing list