1. ¿Existe un problema de rendimiento o mantenimiento de código con el uso assertcomo parte del código estándar en lugar de usarlo solo para fines de depuración?

   Es

   assert x >= 0, 'x is less than zero'

   mejor o peor que

   if x < 0:
       raise Exception, 'x is less than zero'

2. Además, ¿hay alguna forma de establecer una regla de negocio como if x < 0 raise erroresa? Siempre se verifica sin try/except/finallyeso, si en algún momento a lo largo del código xes menor que 0, se genera un error, como si se configura assert x < 0al inicio de una función, en cualquier lugar dentro de la función donde se xconvierte en menos de 0 se genera una excepción?

Para poder lanzar automáticamente un error cuando x sea menor que cero en toda la función. Puedes usar descriptores de clase . Aquí hay un ejemplo:

class LessThanZeroException(Exception):
    pass

class variable(object):
    def __init__(self, value=0):
        self.__x = value

    def __set__(self, obj, value):
        if value < 0:
            raise LessThanZeroException('x is less than zero')

        self.__x  = value

    def __get__(self, obj, objType):
        return self.__x

class MyClass(object):
    x = variable()

>>> m = MyClass()
>>> m.x = 10
>>> m.x -= 20
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "my.py", line 7, in __set__
    raise LessThanZeroException('x is less than zero')
LessThanZeroException: x is less than zero

Las afirmaciones deben usarse para probar condiciones que nunca deberían suceder . El propósito es colapsar temprano en el caso de un estado corrupto del programa.

Deben usarse excepciones para los errores que pueden ocurrir, y casi siempre debe crear sus propias clases de Excepción .

Por ejemplo, si está escribiendo una función para leer desde un archivo de configuración a un dictformato incorrecto en el archivo debería aparecer un ConfigurationSyntaxError, mientras que puede assertque no esté a punto de regresar None.

En su ejemplo, si xse establece un valor a través de una interfaz de usuario o de una fuente externa, lo mejor es una excepción.

Si xsolo lo establece su propio código en el mismo programa, vaya con una aserción.

Las declaraciones de "afirmar" se eliminan cuando se optimiza la compilación . Entonces, sí, hay diferencias funcionales y de rendimiento.

El generador de código actual no emite ningún código para una declaración de aserción cuando se solicita la optimización en tiempo de compilación. - Documentos de Python 2 Documentos de Python 3

Si utiliza assert para implementar la funcionalidad de la aplicación, luego optimice la implementación para la producción, estará plagado de defectos "but-it-works-in-dev".

Ver PYTHONOPTIMIZE y -O -OO

Los cuatro propósitos de assert

Suponga que trabaja en 200,000 líneas de código con cuatro colegas Alice, Bernd, Carl y Daphne. Ellos llaman a tu código, tú llamas a su código.

Luego asserttiene cuatro roles :

1. Informe a Alice, Bernd, Carl y Daphne qué espera su código.
   Suponga que tiene un método que procesa una lista de tuplas y la lógica del programa puede romperse si esas tuplas no son inmutables:

   def mymethod(listOfTuples):
       assert(all(type(tp)==tuple for tp in listOfTuples))

   Esto es más confiable que la información equivalente en la documentación y es mucho más fácil de mantener.

2. Informe a la computadora lo que su código espera.
   assertimpone el comportamiento adecuado de las personas que llaman de su código. Si su código llama al código de Alices y Bernd llama al suyo, entonces sin el assert, si el programa falla en el código de Alices, Bernd podría asumir que fue culpa de Alice, Alice investiga y podría asumir que fue su culpa, usted investiga y le dice a Bernd que en realidad fue su. Mucho trabajo perdido.
   Con afirma, quien recibe una llamada incorrecta, rápidamente podrán ver que fue su culpa, no la suya. Alice, Bernd y todos ustedes se benefician. Ahorra inmensas cantidades de tiempo.

3. Informe a los lectores de su código (incluido usted mismo) qué ha logrado su código en algún momento.
   Suponga que tiene una lista de entradas y que cada una de ellas puede estar limpia (lo cual es bueno) o puede ser borrosa, trale, gullup o centelleante (que no son aceptables). Si es borroso, debe ser desenfadado; si es trale, debe ser baludo; si es gullup, debe ser troteado (y luego posiblemente también estimulado); si está centelleado, debe volver a brillar excepto los jueves. Ya tienes la idea: es algo complicado. Pero el resultado final es (o debería ser) que todas las entradas están limpias. Lo correcto es hacer un resumen del efecto de su ciclo de limpieza como

   assert(all(entry.isClean() for entry in mylist))

   Estas declaraciones ahorran un dolor de cabeza para todos los que intentan entender exactamente qué es lo que está logrando el maravilloso ciclo. Y la más frecuente de estas personas probablemente sea usted mismo.

4. Informe a la computadora lo que su código ha logrado en algún momento.
   Si alguna vez se olvida de marcar una entrada que la necesita después del trote, assertle ahorrará el día y evitará que su código rompa el de Daphne mucho más tarde.

En mi opinión, assertlos dos propósitos de documentación (1 y 3) y salvaguarda (2 y 4) son igualmente valiosos.
Informar a las personas puede ser incluso más valioso que informar a la computadora porque puede evitar los mismos errores que los assertobjetivos deben atrapar (en el caso 1) y muchos errores posteriores en cualquier caso.

Además de las otras respuestas, las afirmaciones arrojan excepciones, pero solo AssertionErrors. Desde un punto de vista utilitario, las afirmaciones no son adecuadas para cuando necesita un control de grano fino sobre las excepciones que captura.

Lo único que está realmente mal con este enfoque es que es difícil hacer una excepción muy descriptiva usando declaraciones de afirmación. Si está buscando la sintaxis más simple, recuerde que también puede hacer algo como esto:

class XLessThanZeroException(Exception):
    pass

def CheckX(x):
    if x < 0:
        raise XLessThanZeroException()

def foo(x):
    CheckX(x)
    #do stuff here

Otro problema es que el uso de la aserción para la verificación de condición normal es que hace que sea difícil deshabilitar las afirmaciones de depuración utilizando el indicador -O.

La palabra del idioma inglés afirmar aquí se usa en el sentido de jurar , afirmar , declarar . No significa "verificar" o "debería ser" . Significa que usted como codificador está haciendo una declaración jurada aquí:

# I solemnly swear that here I will tell the truth, the whole truth, 
# and nothing but the truth, under pains and penalties of perjury, so help me FSM
assert answer == 42

Si el código es correcto, salvo las perturbaciones de evento único , fallas de hardware y demás, ninguna afirmación fallará . Es por eso que el comportamiento del programa para un usuario final no debe verse afectado. Especialmente, una afirmación no puede fallar incluso bajo condiciones programáticas excepcionales . Simplemente nunca sucede. Si sucede, el programador debería ser eliminado por ello.

Como se ha dicho anteriormente, las afirmaciones deben usarse cuando su código NO DEBE llegar a un punto, lo que significa que hay un error allí. Probablemente la razón más útil que puedo ver para usar una aserción es una condición invariante / pre / post. Estos son algo que debe ser cierto al principio o al final de cada iteración de un bucle o una función.

Por ejemplo, una función recursiva (2 funciones separadas, por lo que 1 maneja la entrada incorrecta y la otra maneja el código incorrecto, porque es difícil de distinguir con recursividad). Esto haría obvio si se me olvida escribir la declaración if, lo que salió mal.

def SumToN(n):
    if n <= 0:
        raise ValueError, "N must be greater than or equal to 0"
    else:
        return RecursiveSum(n)

def RecursiveSum(n):
    #precondition: n >= 0
    assert(n >= 0)
    if n == 0:
        return 0
    return RecursiveSum(n - 1) + n
    #postcondition: returned sum of 1 to n

Estos invariantes de bucle a menudo se pueden representar con una afirmación.

¿ Hay algún problema de rendimiento?

• Recuerde "hacer que funcione primero antes de hacerlo rápido" .
  Muy poco porcentaje de cualquier programa suele ser relevante por su velocidad. Siempre puede expulsar o simplificar y assertsi alguna vez resulta ser un problema de rendimiento, y la mayoría de ellos nunca lo hará.

• Sea pragmático :
  suponga que tiene un método que procesa una lista no vacía de tuplas y la lógica del programa se romperá si esas tuplas no son inmutables. Deberías escribir:

  def mymethod(listOfTuples):
      assert(all(type(tp)==tuple for tp in listOfTuples))

  Esto probablemente esté bien si sus listas tienden a tener diez entradas, pero puede convertirse en un problema si tienen un millón de entradas. Pero en lugar de descartar este valioso cheque por completo, simplemente podría degradarlo a

  def mymethod(listOfTuples):
      assert(type(listOfTuples[0])==tuple)  # in fact _all_ must be tuples!

  que es barato pero que probablemente atrapará la mayor parte del todos modos errores reales del programa.

Bueno, esta es una pregunta abierta, y tengo dos aspectos que quiero tocar: cuándo agregar aserciones y cómo escribir los mensajes de error.

Propósito

Para explicárselo a un principiante, las aserciones son declaraciones que pueden generar errores, pero no las detectará. Y normalmente no se deben criar, pero en la vida real a veces se crían de todos modos. Y esta es una situación grave, de la cual el código no puede recuperarse, lo que llamamos un "error fatal".

A continuación, es para 'propósitos de depuración', lo que, aunque es correcto, suena muy desdeñoso. Me gusta más la formulación de 'declarar invariantes, que nunca deberían violarse', aunque funciona de manera diferente en diferentes principiantes ... Algunos 'simplemente lo entienden', y otros no encuentran ningún uso para él o reemplazan las excepciones normales, o incluso controlar el flujo con él.

Estilo

¡En Python, assertes una declaración, no una función! (recuerdaassert(False, 'is true') que no subirá. Pero, teniendo eso fuera del camino:

¿Cuándo y cómo escribir el 'mensaje de error' opcional?

Esto se aplica realmente a los marcos de prueba de unidad, que a menudo tienen muchos métodos dedicados para hacer afirmaciones ( assertTrue(condition), assertFalse(condition), assertEqual(actual, expected)etc.). A menudo también proporcionan una forma de comentar sobre la afirmación.

En el código desechable, podría prescindir de los mensajes de error.

En algunos casos, no hay nada que agregar a la afirmación:

volcado de def (algo): afirmar isinstance (algo, Dumpable) # ...

Pero aparte de eso, un mensaje es útil para la comunicación con otros programadores (que a veces son usuarios interactivos de su código, por ejemplo, en Ipython / Jupyter, etc.).

Bríndeles información, no solo filtrar detalles de implementación internos.

en vez de:

assert meaningless_identifier <= MAGIC_NUMBER_XXX, 'meaningless_identifier is greater than MAGIC_NUMBER_XXX!!!'

escribir:

assert meaningless_identifier > MAGIC_NUMBER_XXX, 'reactor temperature above critical threshold'

o tal vez incluso:

assert meaningless_identifier > MAGIC_NUMBER_XXX, f'reactor temperature({meaningless_identifier }) above critical threshold ({MAGIC_NUMBER_XXX})'

Lo sé, lo sé, este no es un caso para una aserción estática, pero quiero señalar el valor informativo del mensaje.

¿Mensaje negativo o positivo?

Esto puede ser controvertido, pero me duele leer cosas como:

assert a == b, 'a is not equal to b'

• Estas son dos cosas contradictorias escritas una al lado de la otra. Entonces, cada vez que tengo una influencia en la base de código, presiono para especificar lo que queremos, usando verbos adicionales como 'must' y 'should', y no decir lo que no queremos.

  afirmar a == b, 'a debe ser igual a b'

Entonces, obtener AssertionError: a must be equal to btambién es legible, y la declaración parece lógica en el código. Además, puede obtener algo sin leer el rastreo (que a veces ni siquiera puede estar disponible).

Tanto el uso assertcomo el aumento de excepciones tienen que ver con la comunicación.

• Las afirmaciones son declaraciones sobre la exactitud del código dirigido a los desarrolladores : una afirmación en el código informa a los lectores del código sobre las condiciones que deben cumplirse para que el código sea correcto. Una afirmación que falla en tiempo de ejecución informa a los desarrolladores que hay un defecto en el código que necesita ser reparado.

• Las excepciones son indicaciones sobre situaciones no típicas que pueden ocurrir en tiempo de ejecución pero que no pueden resolverse mediante el código en cuestión, que se aborda en el código de llamada que se maneja allí. La aparición de una excepción no indica que hay un error en el código.

Mejores prácticas

Por lo tanto, si considera la ocurrencia de una situación específica en tiempo de ejecución como un error sobre el que desea informar a los desarrolladores ("Hola desarrollador, esta condición indica que hay un error en alguna parte, por favor corrija el código"). ir para una afirmación. Si la aserción verifica los argumentos de entrada de su código, normalmente debe agregar a la documentación que su código tiene un "comportamiento indefinido" cuando los argumentos de entrada violan esas condiciones.

Si, en cambio, la ocurrencia de esa misma situación no es una indicación de un error en sus ojos, sino una posible (quizás rara pero) situación que cree que debería ser manejada por el código del cliente, plantee una excepción. Las situaciones en las que se plantea una excepción deben formar parte de la documentación del código respectivo.

¿Hay algún problema de [...] rendimiento al usar assert

La evaluación de las afirmaciones lleva algún tiempo. Sin embargo, pueden eliminarse en tiempo de compilación. Esto tiene algunas consecuencias, sin embargo, ver más abajo.

¿Hay algún [...] problema de mantenimiento de código al usar assert

Normalmente, las aserciones mejoran la capacidad de mantenimiento del código, ya que mejoran la legibilidad al hacer explícitos los supuestos y durante el tiempo de ejecución verificar regularmente estos supuestos. Esto también ayudará a atrapar regresiones. Sin embargo, hay un problema que debe tenerse en cuenta: las expresiones utilizadas en las afirmaciones no deberían tener efectos secundarios. Como se mencionó anteriormente, las afirmaciones se pueden eliminar en el momento de la compilación, lo que significa que también desaparecerían los posibles efectos secundarios. Esto puede, sin querer, cambiar el comportamiento del código.

Una afirmación es verificar:
1. la condición válida,
2. la declaración válida,
3. lógica verdadera;
del código fuente. En lugar de fallar en todo el proyecto, da la alarma de que algo no es apropiado en su archivo fuente.

En el ejemplo 1, dado que la variable 'str' no es nula. Por lo tanto, no se plantea ninguna afirmación o excepción.

Ejemplo 1:

#!/usr/bin/python

str = 'hello Python!'
strNull = 'string is Null'

if __debug__:
    if not str: raise AssertionError(strNull)
print str

if __debug__:
    print 'FileName '.ljust(30,'.'),(__name__)
    print 'FilePath '.ljust(30,'.'),(__file__)


------------------------------------------------------

Output:
hello Python!
FileName ..................... hello
FilePath ..................... C:/Python\hello.py

En el ejemplo 2, var 'str' es nulo. Por lo tanto, estamos evitando que el usuario se adelante al programa defectuoso al afirmar comunicado.

Ejemplo 2

#!/usr/bin/python

str = ''
strNull = 'NULL String'

if __debug__:
    if not str: raise AssertionError(strNull)
print str

if __debug__:
    print 'FileName '.ljust(30,'.'),(__name__)
    print 'FilePath '.ljust(30,'.'),(__file__)


------------------------------------------------------

Output:
AssertionError: NULL String

En el momento en que no queremos depurar y nos damos cuenta del problema de aserción en el código fuente. Deshabilitar la bandera de optimización

python -O afirmarStatement.py
no se imprimirá nada

En IDE como PTVS, PyCharm, las assert isinstance()declaraciones Wing se pueden usar para permitir la finalización del código para algunos objetos poco claros.

Para lo que vale, si se trata de un código que se basa assertpara funcionar correctamente, agregar el siguiente código garantizará que las afirmaciones estén habilitadas:

try:
    assert False
    raise Exception('Python assertions are not working. This tool relies on Python assertions to do its job. Possible causes are running with the "-O" flag or running a precompiled (".pyo" or ".pyc") module.')
except AssertionError:
    pass