Python Core Library and PEP8

I was trying to understand why Python is said to be a beautiful language. I was directed to the beauty of PEP 8... and it was strange. In fact it says that you can use any convention you want, j开发者_高级运维ust be consistent... and suddenly I found some strange things in the core library:

request()
getresponse()
set_debuglevel()
endheaders()
http://docs.python.org/py3k/library/http.client.html

The below functions are new in the Python 3.1. What part of PEP 8 convention is used here?

popitem()
move_to_end()
http://docs.python.org/py3k/library/collections.html

So my question is: is PEP 8 used in the core library, or not? Why is it like that?

Is there the same situation as in PHP where I cannot just remember the name of the function because there are possible all ways of writing the name?

Why PEP 8 is not used in the core library even for the new functions?

PEP 8 recommends using underscores as the default choice, but leaving them out is generally done for one of two reasons:

• consistency with some other API (e.g. the current module, or a standard interface)
• because leaving them out doesn't hurt readability (or even improves it)

To address the specific examples you cite:

• popitem is a longstanding method on dict objects. Other APIs that adopt it retain that spelling (i.e. no underscore).

• move_to_end is completely new. Despite other methods on the object omitting underscores, it follows the recommended PEP 8 convention of using underscores, since movetoend is hard to read (mainly because toe is a word, so most people's brains will have to back up and reparse once they notice the nd)

• set_debuglevel (and the newer set_tunnel) should probably have left the underscore out for consistency with the rest of the HTTPConnection API. However, the original author may simply have preferred set_debuglevel tosetdebuglevel (note that debuglevel is also an argument to the HTTPConnection constructor, explaining the lack of a second underscore) and then the author of set_tunnel simply followed that example.

• set_tunnel is actually another case where dropping the underscore arguably hurts readability. The juxtaposition of the two "t"s in settunnel isn't conducive to easy parsing.

Once these inconsistencies make it into a Python release module, it generally isn't worth the hassle to try and correct them (this was done to de-Javaify the threading module interface between Python 2 and Python 3, and the process was annoying enough that nobody else has volunteered to "fix" any other APIs afflicted by similar stylistic problems).

From PEP8:

But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!

What you have mentioned here is somewhat consistent with the PEP8 guidelines; actually, the main inconsistencies are in other parts, usually with CamelCase.

The Python standard library is not as tightly controlled as it could be, and the style of modules varies. I'm not sure what your examples are meant to illustrate, but it is true that Python's library does not have one voice, as Java's does, or Win32. The language (and library) are built by an all-volunteer crew, with no corporation paying salaries to people dedicated to the language, and it sometimes shows.

Of course, I believe other factors outweigh this negative, but it is a negative nonetheless.