¿Muchas bibliotecas de Python tienen una calidad de código relativamente baja?

Question

Editar: Desde que se hizo esta pregunta, se han producido muchas mejoras en las bibliotecas científicas estándar de Python (que era el área objetivo). Por ejemplo, el proyecto numpy ha hecho un gran esfuerzo para mejorar las cadenas de documentación. Todavía se puede discutir si hubiera sido posible abordar estos problemas continuamente desde el principio.

---

Tengo una pregunta un tanto herética: ¿Por qué tantas bibliotecas de Python tienen códigos confusos y no siguen las mejores prácticas estándar? ¿O crees que esta observación no es del todo cierta? ¿Cómo se compara la situación con otros idiomas? Estoy interesado en su opinión sobre esto.

Algunas razones por las que tengo la impresión de que falta calidad:

• Las cadenas de documentación a menudo faltan o están incompletas, incluso para la API pública. Es doloroso cuando un método toma * args y ** kwargs pero no documenta qué valores pueden darse.

• Prácticas incorrectas de codificación de Python, como agregar nuevos atributos fuera de __init__ . Cosas como esta hacen que el código sea difícil de leer (o mantener).

• Casi ninguna biblioteca sigue las convenciones de codificación de PEP8. A veces, las convenciones ni siquiera son coherentes en un solo archivo.

• El diseño general es desordenado, sin una API clara. Parece que no se hace suficiente refactorización.

• Cobertura de prueba de unidad deficiente.

No me malinterpretes, amo absolutamente Python y su ecosistema . Y aunque luché con estas bibliotecas, generalmente hacen el trabajo y estoy agradecido por eso . Pero también creo que al final se desperdicia mucho tiempo de desarrollador debido a estos problemas. Tal vez eso se deba a que Python te da tanta libertad que es muy fácil escribir un código incorrecto .

Answer 1

En cuanto a la documentación, no es solo Python. Si hay un solo factor que está impidiendo la adopción más amplia de OSS es, en mi humilde opinión, el nivel verdaderamente terrible de la mayoría de los proyectos de OSS. Esto comienza en el nivel de código y se extiende a los documentos del usuario. ¿Puedo decirle a cualquiera que trabaje en OSS?

a) Comenta tu código! ¡No existe tal cosa como el código de auto-documentación!

b) Gaste al menos el 25% del presupuesto de tiempo del proyecto en la documentación del usuario final.

Y sé vagamente de lo que estoy hablando: tengo un par de proyectos OSS propios, he contribuido a varios otros y uso OSS casi exclusivamente. Y ayer, pasé más de 4 horas tratando de construir un proyecto OSS importante (sin nombres, sin simulacros de paquetes), y fallando debido a la documentación desagradable y contradictoria.

Answer 2

  

En cambio, los autores parecen seguir su gloriosa convención. Y a veces las convenciones ni siquiera son coherentes con el mismo archivo de una biblioteca

¡Bienvenido al maravilloso código del mundo real!

El código Python de FWIW que he encontrado no es mejor ni peor que eso en cualquier otro idioma.

(Bueno, mejor que el proyecto PHP promedio, obviamente, pero eso no es realmente justo)

Answer 3

Lo primero que debe tener en cuenta es que Python no surgió, completamente formado, de la cabeza de Guido en algún momento alrededor de la versión 2.x. Ha crecido a lo largo de los últimos veinte años.

De hecho, varias de las cosas que mencionas (unittest, por ejemplo, y PEP-8), ni siquiera existían cuando se escribieron por primera vez algunas de las bibliotecas estándar.

Probablemente se dará cuenta de que cuanto más antigua sea la biblioteca que está viendo, es más probable que tengan divergencias con las "mejores prácticas" actuales, a menudo porque son anteriores a la adopción generalizada de esas prácticas. Las bibliotecas más recientes tienen más probabilidades de ajustarse a las prácticas actuales.

Además, a veces hay una buena razón para no actualizarlos. Imagina que tienes varias decenas de miles de líneas de código escritas contra las bibliotecas de Python actuales. Ahora, el responsable del mantenimiento de una de esas bibliotecas decide cambiar las bibliotecas para que los nombres de clase y función se ajusten a PEP-8. Ahora, todos los que tienen código de trabajo tienen que volver a visitar grandes cantidades de él, para que el cambio de nombre no se rompa.

Eso no quiere decir que no haya cosas que puedan mejorar en las bibliotecas de Python, ¡las hay! Pero siempre hay una compensación entre la perfección y hacer las cosas. Esa es una razón por la que dicen "La practicidad es mejor que la pureza".

Answer 4

Esto se debe a que Python no está respaldado por el mundo corporativo como Java o .Net.

Si quiero que Sun promueva mi biblioteca Java, seguiré sus pautas. Este no es el caso con Python. Escribo mi código, la gente lo encuentra mejor y tiene que evolucionar por sí solo.

También la mayoría de los desarrolladores de Python son de C ++, C, Java, .Net, etc. Y comienzan a escribir código de producción desde el primer día. Gracias a la facilidad de Python. Y el círculo vicioso continúa.

Incluso me tomó un mes venir a PEP8 y refactorizar mi código.

Answer 5

PEP 8 ha cambiado con el tiempo. Algunos módulos siguen recomendaciones anteriores. Puedes ver eso con PIL, que utiliza módulos como " Imagen " donde el módulo contiene una única clase principal, en lugar de la minúscula recomendada para los nombres de los módulos, y en las extensiones C que usan la " c " prefijo, en lugar de los más modernos " _ " prefijo.

Algunas de las bibliotecas están desarrolladas por personas que están fuertemente influenciadas por las tradiciones en otros campos, como Java y C ++. Estas personas utilizan más a menudo CamelCase en lugar del PEP 8 recomendado en minúsculas con withunderscores.

Las respuestas aquí no estarían completas sin hacer referencia a Ley del esturión : " El noventa por ciento de todo es basura. & Quot;

Answer 6

  

El noventa por ciento de [las bibliotecas de python] son ??crudos, pero el noventa por ciento de todo es crudino

- Ley de esturiones (parafraseado)

Answer 7

Parece que ha llegado a la conclusión de que la calidad del código no cumple con las expectativas que esperaba. Quizás de la escuela, o de las mejores prácticas de libros o desarrolladores senior.

Después de haber trabajado en varias empresas, me recomendaron regularmente hacer pruebas de unidad, documentar códigos, usar el control de versión / fuente (todos los buenos consejos que he tomado) y luego encontrar que quienes dan esos consejos rara vez siguen los consejos. .

Diría que tiene la impresión correcta de que a veces la calidad del código es baja, pero solo en función de sus expectativas. Ciertamente, numpy y otros son paquetes muy útiles, incluso si no están codificados según el estándar que se esperaba.

Los estándares son opiniones, y si usted considera que los estándares son bajos, puede intentar ayudar a mejorar esos estándares contribuyendo o aceptándolos tal como están y asegúrese de escribir un código que sirva de ejemplo para los juniors te encontrarás a cargo de un día.

Answer 8

En cuanto a matplotlib, hay un proyecto para mejorar su " pythoness " - http://www.scipy.org/PyLab

Lo que pasa con las bibliotecas científicas, es que están escritas por científicos, no por desarrolladores de software profesionales. Mover, esos científicos se utilizan para escribir Fortran. La pregunta es: ¿preferiría tener un código de trabajo o un código hermoso?

Answer 9

PEP8 es un estilo guía , no un requisito de estilo. Incluso indica que debes "saber cuándo ser inconsistente". Personalmente, no me gustan algunas de las pautas que contiene. Prefiero camelCase a snake_case ya que estoy más acostumbrado a eso.

Y a menudo no miro el código fuente de las bibliotecas que estoy usando a menos que sea absolutamente necesario (como la depuración). Prefiero la documentación para que dicha biblioteca sea lo suficientemente adecuada para que nunca tenga que mirar la fuente.

En serio, ¿por qué realmente te importa cómo se ve el código fuente de matplotlib , siempre que haga lo que está destinado a hacer?

Estoy de acuerdo con usted en los docstrings que faltan (suponiendo que sean elementos públicos en lugar de elementos internos) pero esa no es la única forma de documentar una biblioteca.

Answer 10

Creo que Python sufre que se le eche demasiado ganas a las personas que no son programadores (a través de la educación o el comercio) como una solución para "¿se necesita algún tipo de programación? Aquí, prueba esta herramienta fácil y madura " ;.

De manera similar a cómo PHP se convirtió en un gran éxito y con tantas bibliotecas con una calidad de código abismal (incluso si, concedida, la calidad promedio del código de Python es mejor que para PHP): el usuario de PHP promedio es similar al usuario de Python promedio no tienen mucha experiencia o habilidades de programación y muy pocos incentivos para superarse a sí mismos en este aspecto; se proponen lograr algo, y tal vez pensaron que es lo suficientemente valioso como para compartirlo con la comunidad en forma de biblioteca, pero la mayoría de las veces, una vez que el trabajo está hecho, no tienen ningún interés en mejorar el código o en mejorar ellos mismos (me refiero a las habilidades de programación).

La solución podría ser que los repositorios de la biblioteca de Python (como PyPI) tengan reglas más estrictas sobre la aceptación de paquetes contribuidos. Maneje esto con un proceso de revisión cuyo objetivo es garantizar la calidad, de la misma manera que las principales distribuciones de Linux tienen un proceso de revisión antes. añadiendo un paquete a sus repositorios.

Answer 11

PEP8 es solo eso, una convención, no un requisito. Sería muy triste que todos los programadores de Python tuvieran adherirse a un conjunto común de reglas, perdemos entusiasmo por el más mínimo de los problemas.

En lo que respecta a las cadenas de documentación faltantes, sí, pueden ser útiles cuando se utiliza la ayuda interactiva, pero en general no me importa siempre que haya documentación en algunos . Intento no leer el código fuente de las bibliotecas que uso, tiendo a comenzar a modificarlas (reescribirlas).

Answer 12

En cuanto a la comparación con otros idiomas, creo que el diseño del idioma juega un papel importante aquí. Por ejemplo, en un lenguaje de tipo fuerte como Java, incluso si a la biblioteca le falta buena documentación, aún puede deducir gran parte de la funcionalidad de las firmas del método. No hay * args con el que lidiar.

Answer 13

¿Qué tal una colección de ejemplos de buen software doc?
Los buenos ejemplos pueden conducir a una mejora general un poco más rápida que la caminata aleatoria.
La colección podría dividirse en categorías como:
documento en línea / página de ayuda / tutorial / manual de referencia, página web / papel, imágenes / ninguno.
Cada entrada debe tener algunas palabras sobre por qué al revisor le parece bueno.
(¿Dónde: una esquina de stackoverflow?)

Answer 14

nikow: solo puedo responder por mí mismo, la mayor parte de mi trabajo en Python (y PHP o Ruby, todos los dinámicos " scripting " lenguajes) se realiza solo para mí , pero siempre lo libero en mi sitio personal, si alguien más lo encuentra útil, pero nunca realizo ningún proceso de documentación o control de calidad porque siempre y cuando funcione para mí, estoy feliz.

Answer 15

Bueno, son de código abierto. Como tales, también evolucionarán con el tiempo, si son lo suficientemente buenos.

Esa es una de las muchas bellezas del código abierto.

A menudo, tiene poco sentido escribir gran cantidad de documentación y " buena " Código si no sabes si el proyecto vivirá. Eso solo sería una pérdida de tiempo.

Edit: Por supuesto, escribir un buen código nunca lastimaría la primera vez, aunque ... Pero tal vez solo "haga el trabajo" Es suficientemente bueno en muchos casos. Creo que de lo contrario no disfrutaríamos de la gran cantidad de opciones cuando se trata de OSS.

Creo que si suficientes personas actúan de una manera específica, podría haber alguna explicación. No solo lo hacen al azar para ofenderte.

Answer 16

Calidad del código * número de comentarios * tiempo = constante

¡Elige dos!

Nunca tuve ningún problema al utilizar matplotlib; No puedo decir que miré mucho el código, es una buena biblioteca. Hace lo que se supone que debe hacer (¡gratis!)