fail - python assert
¿Por qué afirmar no se usa en gran medida? (4)
Descubrí que la declaración de afirmación de Python es una buena forma de atrapar situaciones que nunca deberían suceder . Y se puede eliminar mediante la optimización de Python cuando se confía en que el código es correcto.
Parece ser un mecanismo perfecto para ejecutar aplicaciones de Python en modo de depuración. Pero al observar varios proyectos de Python como django, twisted y zope, casi nunca se usa la afirmación. ¿Entonces, por qué pasa ésto?
¿Por qué las aseveraciones de afirmaciones no se usan con frecuencia en la comunidad de Python?
No soy autor de ninguno de esos proyectos, así que esto es solo una suposición basada en mis propias experiencias. Sin preguntar directamente a las personas en esos proyectos, no obtendrás una respuesta concreta.
Assert es excelente cuando intenta depurar, etc. en su propia aplicación. Como se indica en el enlace que proporcionó, sin embargo, usar un condicional es mejor cuando la aplicación puede predecir y recuperar un estado. No he usado zope, pero tanto en Twisted como en Django, sus aplicaciones pueden recuperarse y continuar de muchos errores en su código. En cierto sentido, ya han "compilado" las afirmaciones, ya que realmente pueden manejarlas.
Otra razón, relacionada con eso, es que a menudo las aplicaciones que usan bibliotecas externas como las que mencionaste pueden querer manejar errores. Si la biblioteca simplemente usa aserciones, no importa cuál sea el error, generará un AssertionError . Con un condicional, las bibliotecas pueden arrojar errores útiles que su aplicación puede capturar y manejar.
Según mi experiencia, las afirmaciones se usan principalmente en la fase de desarrollo de un programa: para verificar las entradas definidas por el usuario. assert no son realmente necesarias para detectar errores de programación. Python en sí es muy capaz de atrapar errores de programación genuinos como ZeroDivisionError, TypeError o más.
Supongo que la razón principal para assert no se usa con más frecuencia es que nadie usa el modo "optimizado" de Python .
Las aseveraciones son una gran herramienta para detectar errores de programación, para protegerse de situaciones inesperadas, pero todas estas comprobaciones de errores tienen un costo. En lenguajes compilados como C / C ++, esto realmente no importa, ya que las afirmaciones solo están habilitadas en las versiones de depuración, y se eliminan por completo de las compilaciones de versiones.
En Python, por otro lado, no hay una distinción estricta entre el modo de depuración y el de liberación . El intérprete presenta un "indicador de optimización" ( -O ), pero actualmente esto no optimiza el código de bytes, pero solo elimina los asertos.
Por lo tanto, la mayoría de los usuarios de Python simplemente ignoran el indicador -O y ejecutan sus scripts en "modo normal", que es como el modo de depuración, ya que las __debug__ están habilitadas y __debug__ es True , pero se considera "listo para producción".
Tal vez sería más inteligente cambiar la lógica, es decir, "optimizar" de forma predeterminada y solo habilitar las afirmaciones en un modo de depuración explícito (*), pero supongo que esto confundiría a muchos usuarios y dudo que veamos un cambio así. .
((*) Esto es, por ejemplo, cómo lo hace Java VM, al presentar un -ea (enable assertions).)
Varias razones vienen a la mente ...
No es una función primaria
Muchos programadores, por no dejar que se atasquen con el razonamiento, faltan el respeto a cualquier cosa que no sea un participante directo en la penúltima funcionalidad del programa. La declaración de afirmación está destinada a la depuración y prueba, y por lo tanto, un lujo que no pueden permitirse.
Examen de la unidad
La declaración de afirmación es anterior al aumento y al aumento de las pruebas unitarias. Mientras que la declaración de afirmación aún tiene sus aplicaciones, la prueba unitaria ahora se usa ampliamente para construir un entorno hostil con el que eliminar la basura de una subrutina y su sistema. Bajo estas condiciones, las afirmaciones afirman que comienzan a sentirse como cuchillos en un tiroteo.
Mejora del respeto de la industria por las pruebas
La declaración de afirma sirve mejor como la última línea de defensa. Alcanzó alturas elevadas e intocables bajo el lenguaje C, cuando ese lenguaje dominaba el mundo, como una excelente forma de implementar la nueva "programación defensiva"; reconoce y atrapa desastres catastróficos en el momento en que se balancean al borde. Esto fue antes de que el valor de Testing fuera ampliamente reconocido y respetado y los desastres fueran sustancialmente más comunes.
Hoy en día, es inaudito que se publique cualquier software comercial serio sin algún tipo de prueba. Las pruebas se toman en serio y se han convertido en un campo masivo. Hay profesionales de Pruebas y departamentos de Garantía de Calidad con grandes listas de verificación y firmas formales. En estas condiciones, los programadores no suelen molestarse en afirmar porque tienen la certeza de que su código será sometido a tantas pruebas tediosas que las probabilidades de que se produzca un desastre en el borde del desastre son tan remotas que resultan insignificantes. Eso no quiere decir que tengan razón, pero si la culpa de la programación perezosa se puede trasladar al departamento de control de calidad, ¿por qué no?