La mayoría de las respuestas aquí son bastante antiguas, y especialmente las aceptadas, por lo que parece que vale la pena actualizarlas.
Primero, las preguntas frecuentes oficiales de Python cubren esto, y recomiendan la elif
cadena para casos simples y dict
para casos más grandes o más complejos. También sugiere un conjunto de visit_
métodos (un estilo utilizado por muchos marcos de servidores) para algunos casos:
def dispatch(self, value):
method_name = 'visit_' + str(value)
method = getattr(self, method_name)
method()
Las preguntas frecuentes también mencionan PEP 275 , que fue escrito para obtener una decisión oficial de una vez por todas sobre la adición de declaraciones de cambio de estilo C. Pero esa PEP se aplazó a Python 3, y solo se rechazó oficialmente como una propuesta separada, PEP 3103 . La respuesta fue, por supuesto, no, pero las dos PEP tienen enlaces a información adicional si está interesado en los motivos o el historial.
Una cosa que surgió varias veces (y se puede ver en PEP 275, a pesar de que se recortó como una recomendación real) es que si realmente le molesta tener 8 líneas de código para manejar 4 casos, frente a los 6 líneas que tendrías en C o Bash, siempre puedes escribir esto:
if x == 1: print('first')
elif x == 2: print('second')
elif x == 3: print('third')
else: print('did not place')
Esto no es exactamente alentado por PEP 8, pero es legible y no demasiado unidiomático.
Durante más de una década desde que se rechazó el PEP 3103, el tema de las declaraciones de casos de estilo C, o incluso la versión un poco más poderosa en Go, se ha considerado muerto; cada vez que alguien lo menciona en python-ideas o -dev, se les remite a la antigua decisión.
Sin embargo, la idea de la coincidencia completa de patrones de estilo ML surge cada pocos años, especialmente desde que lenguajes como Swift y Rust lo han adoptado. El problema es que es difícil aprovechar la coincidencia de patrones sin tipos de datos algebraicos. Si bien Guido ha simpatizado con la idea, a nadie se le ocurrió una propuesta que se adapte muy bien a Python. (Puede leer mi Strawman 2014 para ver un ejemplo.) Esto podría cambiar con dataclass
3.7 y algunas propuestas esporádicas para un enum
tipo de suma más potente para manejar, o con varias propuestas para diferentes tipos de enlaces de declaración local (como PEP 3150 , o el conjunto de propuestas actualmente en discusión sobre -ideas). Pero hasta ahora, no lo ha hecho.
También hay ocasionalmente propuestas para la coincidencia de estilo Perl 6, que es básicamente una mezcla de todo, desde elif
expresiones regulares hasta cambio de tipo de despacho único.
switch
en realidad es más "versátil" que algo que devuelve diferentes valores fijos en función del valor de un índice de entrada. Permite ejecutar diferentes piezas de código. En realidad, ni siquiera necesita devolver un valor. Me pregunto si algunas de las respuestas aquí son buenos reemplazos para unaswitch
declaración general , o solo para el caso de devolver valores sin posibilidad de ejecutar partes generales de código.