[Python-Dev] PEP 8 updates/clarifications

[Josiah Carlson]

Reinhold Birkenfeld <reinhold-birkenfeld-nospam at wolke7.net> wrote:
> Ian Bicking wrote:
> > Guido van Rossum wrote:
> >> It doesn't matter. Many large projects are adopting the camelCase
> >> convention, either by choice or by accident. I did a brief review of
> >> Zope 3 and Chandler, and while neither is consistent, camelCase
> >> prevails (Chandler also has a lot of CapWords method names, wihch
> >> suggests they didn't get this from Java -- maybe from C++?).
> > 
> > Everything that touches wx seems to adopt CapWords method names -- in 
> > part (hopefully) or in whole.  Wx's API comes from Windows, and the 
> > Microsoft method conventions.
> 
> Bad, that. While the Windows API names once made sense when they referred to
> standalone functions, not methods, they now look ugly in wx or .NET.

In regards to naming conventions, I find that CapWords are easier for me
to read and remember as a native speaker of english.  I've heard
statements from non-native english speakers that CapWords are hard to
read and/or understand, but in the realm of wxPython, changing literally
thousands of CapWords references to lower_underscore during wrapping,
along with the hundreds of thousands of references in just a few of the
larger wxPython projects is a bit out of line.  Or even convincing the
hundreds of other packages which use CapWords or lower_underscore to
change how their naming conventions work is going to be a tough fight.

Personally, I'm of the opinion that as long as a module or package uses
consistant naming semantics, whether it is CapWords, camelCase, or
lower_underscore (all of which beat lowerwithoutspaces), then users of
that module or package should be able to cope.  Yeah, consistancy
cross-packages would be nice, heck consistancy in the standard library
would be nice, but changing the naming in the standard library for a
purity argument, I think, is a red herring.

 - Josiah