Python Core Library and PEP8

Question

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, just 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?

Answer 1

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).