The Python standard library and PEP8

[Gabriel Genellina]

En Sun, 19 Apr 2009 13:43:10 -0300, Emmanuel Surleau  
<emmanuel.surleau at gmail.com> escribió:

> Exploring the Python standard library, I was surprised to see that  
> several
> packages (ConfigParser, logging...) use mixed case for methods all over  
> the
> place. I assume that they were written back when the Python styling
> guidelines were not well-defined.

The name policy changed in March 2004. Before that, PEP8 said:

     Function Names

       Plain functions exported by a module can either use the CapWords
       style or lowercase (or lower_case_with_underscores).  There is
       no strong preference, but it seems that the CapWords style is
       used for functions that provide major functionality
       (e.g. nstools.WorldOpen()), while lowercase is used more for
       "utility" functions (e.g. pathhack.kos_root()).

The current version says:

     Function Names

       Function names should be lowercase, with words separated by  
underscores
       as necessary to improve readability.

       mixedCase is allowed only in contexts where that's already the
       prevailing style (e.g. threading.py), to retain backwards  
compatibility.

> Given that it's rather irritating (not to mention violating the  
> principle of
> least surprise) to have this inconsistency, wouldn't it make sense to  
> clean
> up the API by marking old-style, mixed-case methods as deprecated (but
> keep them around anyway) and add equivalent methods following the
> lowercase_with_underscores convention?

The threading module has such aliases, but there are no plans for mass  
renaming all the stdlib that I know of. You'll have to live with this  
inconsistency.

> On an unrelated note, it would be *really* nice to have a length  
> property on
> strings. Even Java has that!

Why would it be nice to have? I never missed it...

-- 
Gabriel Genellina