En Sun, 19 Apr 2009 13:43:10 -0300, Emmanuel Surleau
<emmanuel.surl...@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
--
http://mail.python.org/mailman/listinfo/python-list
