online - ¿Por qué el módulo de registro de Python no sigue las convenciones de PEP8?
pep8 pycharm (1)
Esto es solo una curiosidad con propósitos históricos:
Me preguntaba si alguien sabe por qué el logging muy utilizado (y el módulo principal) no sigue la convención de nomenclatura PEP-8 de Python.
Por ejemplo, en
>>> import logging
>>> log = logging.getLogger("hello")
Espero que sea get_logger , pero no lo es.
Cuando se trata de nombres de funciones , el estándar PEP8 dice:
mixedCase solo se permite en contextos donde ese ya es el estilo predominante (por ejemplo, threading.py), para conservar la compatibilidad con versiones anteriores.
¿Fue ese el caso? Si es así, ¿con qué otra cosa de logging tenía que mantener la compatibilidad con versiones anteriores? ¿O fue solo que los desarrolladores de logging sintieron como usar nombres de camel-case?
Por supuesto, el módulo está bien documentado y no es un gran problema en absoluto . Tengo curiosidad.
El módulo de logging fue desarrollado por una empresa independiente en 2001 y se basó en gran medida en Log4j. Como tal, sigue las convenciones de nomenclatura que eligió el autor original, que reflejan las opciones de Log4j; el último tiene un método getLogger() también .
Hasta un año más tarde, el PEP 282 no propuso agregarlo a la biblioteca estándar, momento en el cual la convención de nomenclatura se estableció en piedra.
Es un problema conocido con el paquete , pero no es el único paquete que viola el PEP. De la Wiki enlazada:
PEP8 dice: la coherencia con esta guía de estilo es importante. La consistencia dentro de un proyecto es más importante. La consistencia dentro de un módulo o función es lo más importante.
- Es cierto, pero no se puede cambiar, debido a la compatibilidad con versiones anteriores. logging2 tal vez. - techtonik
- Es una prioridad baja en este momento, a menos que haya una iniciativa para garantizar que el resto de la tabla estándar se haga conforme a PEP8. - VinaySajip
Por último, pero no menos importante, la propia guía de estilo tiene esto que decir sobre la aplicación de guías de estilo:
Una consistencia tonta es el Hobgoblin de Little Minds
Una guía de estilo es sobre la consistencia. La coherencia con esta guía de estilo es importante. La consistencia dentro de un proyecto es más importante. La consistencia dentro de un módulo o función es lo más importante.
Pero lo más importante: saber cuándo ser inconsistente, a veces la guía de estilo simplemente no se aplica. En caso de duda, utiliza tu mejor juicio. Mira otros ejemplos y decide qué se ve mejor. ¡Y no dudes en preguntar!
En particular: ¡no rompa la compatibilidad hacia atrás solo para cumplir con este PEP!
El logging ''reparación'' rompería la compatibilidad hacia atrás, lo que no vale la pena.