raw_input - input python 3

¿Cuánta validación de entrada debo hacer en mis funciones/métodos de python?

Question

Estoy interesado en la cantidad de validación inicial que las personas hacen en el Python que escriben.

Aquí hay algunos ejemplos de funciones simples:

def factorial(num):
"""Computes the factorial of num."""
def isPalindrome(inputStr):
"""Tests to see if inputStr is the same backwards and forwards."""
def sum(nums):
"""Same as the built-in sum()... computes the sum of all the numbers passed in."""

¿Qué tan exhaustivamente verifica los valores de entrada antes de comenzar a calcular, y cómo hace su verificación? ¿Lanza algún tipo de excepción propietaria si la entrada es incorrecta (BadInputException definida en el mismo módulo, por ejemplo)? ¿Acaba de comenzar su cálculo y calcula que emitirá una excepción en algún momento si se pasaron datos incorrectos ("asd" a factorial, por ejemplo)?

Cuando se supone que el valor pasado es un contenedor, ¿comprueba no solo el contenedor sino también todos los valores que contiene?

¿Qué pasa con situaciones como factorial, donde lo que se transmite puede ser convertible a un int (por ejemplo, un flotador) pero puede perder precisión al hacerlo?

Answer 1

Para cálculos como sum, factorial, etc., las comprobaciones de tipos incorporadas de pitones funcionarán bien. Los cálculos terminarán añadiendo upp llamando, mul etc. para los tipos, y si se rompen, lanzarán la excepción correcta de todos modos. Al aplicar sus propios controles, puede invalidar la entrada que de otro modo funcionaría.

Answer 2

Casi nunca hago cumplir ningún tipo de control, a menos que crea que hay una posibilidad de que alguien piense que puede pasar algo de X, lo que produciría resultados completamente disparatados.

La otra vez que verifico es cuando acepto varios tipos para un argumento, por ejemplo, una función que toma una lista, podría aceptar un objeto arbitrario y simplemente envolverlo en una lista (si aún no es una lista). Entonces, en ese caso, verifico el tipo -no para hacer cumplir nada- solo porque quiero que la función sea flexible en la forma en que se usa.

Answer 3

Intento escribir docstring indicando qué tipo de parámetro se espera y se acepta, y no lo estoy verificando explícitamente en mis funciones.

Si alguien quiere usar mi función con cualquier otro tipo, es su responsabilidad verificar si su tipo emula uno, lo acepto lo suficientemente bien. ¿Tal vez su factorial se puede usar con algún tipo largo personalizado para obtener algo en lo que no se podría pensar? ¿O tal vez su suma se puede usar para concatenar cadenas? ¿Por qué debería rechazarlo mediante la verificación de tipos? No es C, de todos modos.

Answer 4

Básicamente trato de convertir la variable a lo que debería ser y dejarla pasar o lanzar la excepción apropiada si eso falla.

def factorial(num):
"""Computes the factorial of num."""
try:
num = int(num)
except ValueError, e:
print e
else:
...

Answer 5

Más bien depende de lo que estoy escribiendo, y cómo la salida llega allí. Python no tiene las protecciones públicas / privadas de otros OO-languages. En cambio, hay convenciones. Por ejemplo, el código externo solo debe llamar a métodos de objetos que no están prefijados por un guión bajo.

Por lo tanto, si estoy escribiendo un módulo, validaría cualquier cosa que no se haya generado desde mi propio código, es decir, cualquier llamada a métodos / funciones de acceso público. A veces, si sé que la validación es costosa, la hago seleccionable con un kwarg:

def publicly_accessible_function(arg1, validate=False):
if validate:
do_validation(arg1)
do_work

Los métodos internos pueden hacer la validación a través de la declaración afirmativa , que se puede desactivar por completo cuando el código sale del desarrollo y entra en producción.

Answer 6

Solo se molestará en verificar si tiene una prueba de unidad defectuosa que lo obligue a hacerlo.

Considera también " EAFP " ... ¡Es la forma de Python!

Answer 7

assert lo que es absolutamente esencial.

Importante: lo que es absolutamente esencial. Algunas personas sobrevaloran cosas.

def factorial(num):
assert int(num)
assert num > 0

No es completamente correcto siempre es una posibilidad legal.

def factorial(num):
assert type(num) in ( int, long )
assert num > 0

Es mejor, pero aún no es perfecto. Muchos tipos de Python (como números racionales u objetos similares a números) también pueden funcionar en una buena función factorial. Es difícil afirmar que un objeto tenga propiedades básicas tipo enteros sin ser demasiado específico y que se eliminen de consideración las clases futuras no pensadas.

Nunca defino excepciones únicas para funciones individuales. Defino una excepción única para un módulo o paquete significativo. Por lo general, sin embargo, solo una clase de Error o algo similar. De esa forma la aplicación dice except somelibrary.Error,e: que es todo lo que necesitas saber. Las excepciones de grano fino se vuelven quisquillosas y tontas.

Nunca he hecho esto, pero puedo ver lugares donde podría ser necesario.

assert all( type(i) in (int,long) for i in someList ) 

En general, sin embargo, las comprobaciones de tipo de función incorporadas de Python funcionan bien. Encuentran casi todas las situaciones excepcionales que importan casi todo el tiempo. Cuando algo no es del tipo correcto, Python genera un TypeError que siempre apunta a la línea derecha de código.

Por cierto. Solo agrego afirmaciones en el momento del diseño si estoy absolutamente seguro de que se abusará de la función. A veces agrego afirmaciones más adelante cuando tengo una prueba de unidad que falla de una manera oscura.

Answer 8

Un poco de perspectiva sobre cómo maneja otro lenguaje podría agregar algún valor. Para Perl, recuerdo haber usado este módulo - http://search.cpan.org/dist/Params-Validate/, que descarga gran cantidad de validación de parámetros del desarrollador. Estaba buscando algo similar en Python y encontré esto: http://www.voidspace.org.uk/python/validate.html No lo he probado. Pero supongo que el objetivo de una forma estándar de validación de parámetros en toda la base de código conduce a la configuración inicial de las expectativas de validación de parámetros en todo el equipo.