Python Core Library y PEP8

Question

Estaba tratando de entender por qué se dice que Python es un lenguaje hermoso. Me dirigieron a la belleza de PEP 8 ... y fue extraño. De hecho, se dice que se puede utilizar cualquier convención que desea, simplemente ser coherente ... y de repente me encontré algunas cosas extrañas en la biblioteca central:

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

Las siguientes funciones son nuevas en el Python 3.1. ¿Qué parte de la convención PEP 8 se usa aquí?

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

Así que mi pregunta es: ¿PEP 8 utiliza en la biblioteca central, o no? ¿Por qué es así?
¿Existe la misma situación que en PHP donde no puedo simplemente recordar el nombre de la función porque hay posibles todas las formas de escribir el nombre?

¿Por qué no se utiliza PEP 8 en la biblioteca central incluso para las nuevas funciones?

Answer 1

De PEP8:

Pero lo más importante: saber cuándo ser inconsistente - a veces el libro de estilo simplemente no se aplica. En caso de duda, use su mejor juicio. Mire en otros ejemplos y decida qué se ve mejor. Y no dude en preguntar!

Lo que ha mencionado aquí es algo consistente con las pautas PEP8; en realidad, las principales incoherencias se encuentran en otras partes, generalmente con CamelCase.

Answer 2

La biblioteca estándar de Python no está tan estrechamente controlada como podría y el estilo de los módulos varía. No estoy seguro de lo que sus ejemplos deben ilustrar, pero es cierto que la biblioteca de Python no tiene una sola voz, como Java, o Win32. El idioma (y la biblioteca) están construidos por un equipo de voluntarios, sin corporaciones que pagan sueldos a las personas dedicadas al idioma, y ​​a veces se muestra.

Por supuesto, creo que otros factores superan este aspecto negativo, pero no obstante es negativo.

Answer 3

PEP 8 recomienda el uso de subrayado como la opción por defecto, pero dejándolos a cabo generalmente se realiza por una de dos razones:

• consistencia con algún otro API (por ejemplo, el módulo actual, o una interfaz estándar)
• porque dejarlos fuera no hace daño a la legibilidad (o incluso lo mejora)

Para hacer frente a los ejemplos específicos que usted cita:

• popitem es un método de larga data en objetos dict. Otras API que lo adoptan conservan esa ortografía (es decir, sin subrayado).

• move_to_end es completamente nuevo.A pesar de otros métodos en el objeto omitiendo guiones bajos, sigue la convención recomendada PEP 8 de usar guiones bajos, ya que movetoend es difícil de leer (principalmente porque toe es una palabra, por lo que la mayoría de los cerebros tendrán que respaldar y volver a analizar una vez que noten el nd)

• set_debuglevel (y el más nuevo set_tunnel) probablemente debería haber dejado el guión a cabo para mantener la coherencia con el resto de la API HTTPConnection. Sin embargo, el autor original puede simplemente haber preferido set_debuglevel a setdebuglevel (tenga en cuenta que debuglevel también es un argumento para el constructor HTTPConnection, explicando la falta de un segundo guión bajo) y luego el autor de set_tunnel simplemente siguió ese ejemplo.

• set_tunnel es en realidad otro caso en el que dejar caer el subrayado podría perjudicar la legibilidad. La yuxtaposición de las dos "t" en settunnel no conduce a un análisis sencillo.

Una vez que estas inconsistencias hacen en un módulo de liberación de Python, por lo general, no vale la pena la molestia de tratar de corregirlos (esto se hizo para de-Javaify la interfaz entre threading módulo de Python 2 y Python 3, y el proceso fue lo suficientemente molesto como para que nadie más se haya ofrecido voluntario para "arreglar" cualquier otra API afectada por problemas estilísticos similares).