Yet Another Case Question

Peter Hansen peter at engcorp.com
Tue Feb 25 09:32:09 EST 2003


Steve Holden wrote:
> 
> "Greg Ewing (using news.cis.dfn.de)" <me at privacy.net> wrote in message
> news:b3el7r$1l3jvo$1 at ID-169208.news.dfncis.de...
> > Alex Martelli wrote:
> > > Case sensitivity does NOT enforce the common coding convention
> > > you seem to like so much.  Don't you think math.pi IS a constant?
> > > Yet it's not in ALLCAPS, isn't it?  What about class async_chat
> > > in module asynchat?  Isn't it a class?  So where are its InitialCaps?
> > > And what about function AudioDev in module audiodev -- it's a
> > > function, yet, where is its initialLowerCase...?  We can go on
> > > finding examples for hours even just withing the Python standard
> > > library, so what "enforcement" are you TALKING about?!
> >
> > The Python standard library certainly leaves something
> > to be desired in the area of uniform naming conventions.
> > But to me that's an argument for tidying it up, and
> > documenting a set of conventions for future contributors
> > to follow -- not for abandoning case-sensitivity.
> 
> PyCon sprint, anyone?

Is a sprint necessary to formulate and agree on standards for future
contributions?  Or are you suggesting a sprint to revise the standard
library to use a consistent convention?

I have no opinion on either of the above, but I just want to note that
there was a time when the OS/2 APIs were somewhat inconsistent and IBM
at one point revised all of them to be *strictly* CamelCase, ensuring
that even something like HTTPSocketServer would be written, without the
need for thought, as HttpSocketServer.  (That is, *never* keep acronyms
as ALLCAPS in mixedCase; I heartily approve.)

-Peter




More information about the Python-list mailing list