[Python-Dev] Naming conventions in Py3K

[Brett Cannon]

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