Stack Overflow en español

abulafia

6:02 PM

@MauricioContreras Sí. O que no poner ningún return y que la función termine

Mauricio Contreras

@abulafia debo poner un return. XD

abulafia

@MauricioContreras Ok, solo decía. return explícito sin argumento y return implícito, ambos son equivalentes a return None

Mauricio Contreras

@abulafia eso, es para la docu. Es que tengo el típico validador:

def valida(algo):
    if not algo == algun_valor:
        return
    return algo

Obviamente eso está resumido, sin varias validaciones en esa función, van en cascada, pero si falla alguna devuelve None.

abulafia

No sería más correcto lanzar una excepción ValueError que retornar None ?

Mauricio Contreras

@abulafia si, pero nos pidieron explícitamente no usar try except

abulafia

6:06 PM

ok

pero no dijeron nada de raise :-)

entiendo que esa restricción era para evitar validaciones del estilo valor = int(cadena) y dejar que rompa

ya que veo que andas con Nones a vueltas, cuidado a la hora de comparar una variable (o el valor retornado por tu validador) con None

Mauricio Contreras

Dice así:

Estas comprobaciones no se deben gestionar mediante excepciones.

abulafia

debe hacerse así: if resultado is None en vez de así: if resultado == None

@MauricioContreras Si, parece que mejor olvidar el raise también, por si acaso

Mauricio Contreras

Las restricciones son estas:

En su resolución se deberá programar el menú de forma que cada opción se realice implementando una función. Caso de introducir una opción fuera del rango de 1 a 6, no debe terminar el programa, sino que debe advertirlo para que se vuelva a seleccionar otro punto del menú.

El programa sólo terminará cuando se seleccione la opción 6. Se comprobará que el NIF contiene 9 caracteres, los 8 primeros numéricos. A su vez, el teléfono debe contener 9 dígitos. También se puede comprobar la fecha. Estas comprobaciones no se deben gestionar mediante excepciones.

abulafia

@MauricioContreras Si la lógica de tu programa consiste en recoger el valor devuelto y compararlo con None, yo pondría un return None explícito, para que quede más claro al lector que estás retornando None a propósito y no inadvertidamente

pero no sé si me gusta mucho ese patrón de retornar, bien None, bien el valor validado. Igual era más lógico retornar True o False según pase o no pase las validaciones

al menos desde el punto de vista del tipo retornado es más consistente

si hubiera que declarar el tipo, sería más sencillo hacerlo cuando retornas True o False que cuando retornas str o None

los None acaban siendo una plaga (cuando empiezas a usar Python tipado), equivalente en cierto modo a los punteros nulos del java

Mauricio Contreras

Vale

Lo pillo, la mala costumbre de JS

Gracias

abulafia

6:21 PM

Lo de que python no tenga tipos está muy bien para scripts cortos y prototipado rápido. Pero para proyectos grandes el ir tipando las cosas ayuda mucho. Sobre todo para que los IDEs te vayan detectando errores "en tiempo de escritura" en vez de en tiempo de ejecución

y cuando empiezas a poner tipos a las cosas te das cuenta que tener una variable que pueda tener, bien un tipo, bien None, es una pesadilla. Aunque el sistema de tipado lo permite (por ejemplo si puede tener tanto una cadena como None, declararías su tipo como Optional[str]), eso no suele ser de ayuda al validador o el IDE

ya que si tienes una variable de ese tipo e intentas len(variable) el validador no puede saber si la línea es correcta. Si variable fuese str estaría bien, pero si vale None estaría mal. Así que acaba dándote un warning

mauricio

compañeros, no se soy solo yo pero cuando practico programando, suelo escuchar melodias o soundstrack

Transcript for