The Python standard library and PEP8
Gabriel Genellina
gagsl-py2 at yahoo.com.ar
Sun Apr 19 13:37:59 EDT 2009
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
More information about the Python-list
mailing list