Autor: Pea cat
Fuente: Python Cat
En este artículo, hablaremos sobre por qué Python decidió no admitir la declaración de cambio.
¿Por qué quieres hablar de este tema?
Principalmente porque el cambio es demasiado común en otros lenguajes, pero python no lo admite. Esta singularidad en sí misma es digna de atención. Responder a esta pregunta también puede ayudarlo a ver más claramente el concepto de Python en la programación y comprender el diseño gramatical de Python. En el proceso de toma de decisiones.
Además de analizar PEP-275 y PEP-3103 en detalle, este artículo también presentará los últimos desarrollos en Python (PEP-622), es decir, la sintaxis de coincidencia de patrones que se puede introducir. Creo que este tema ampliará los horizontes de todos. Para tener una comprensión más completa de la gramática del cambio.
1. ¿Qué es el interruptor?
Antes de comenzar con el tema, necesitamos hablar sobre qué es el interruptor.
Algunos estudiantes pueden pensar en ello por primera vez ...
Hey ~ hey ~, por favor cuídese, no piense siempre en el juego, vamos a hablar sobre la declaración de cambio en el lenguaje de programación.
En términos generales, el formato de sintaxis de switch es el siguiente:
switch (expresión) {
caso valor1:
//
salto de instrucción ; //
caso opcional valor2:
//
salto de instrucción ; //
valor predeterminado opcional :
// instrucción // opcional
}
Use el diagrama de flujo para expresar, se ve así:
Su uso no es difícil de entender: en cuyo caso el valor de la instrucción switch satisface, se ejecutará el bloque de código correspondiente y saltará cuando encuentre una ruptura durante la ejecución, de lo contrario continuará ejecutando la siguiente rama del caso; generalmente, una rama predeterminada se colocará al final , Como la parte inferior del bolsillo.
La mayoría de los lenguajes proporcionan sentencias de cambio o cosas muy similares. Por ejemplo, en lenguajes estáticos como C / C ++ / Java / Go, todos admiten la estructura de cambio de caso; en Ruby hay una estructura de caso-cuando similar, en Shell En el lenguaje, hay una estructura similar de mayúsculas y minúsculas, en Perl, hay switch-case-else ...
La ventaja de la instrucción switch es que admite la estructura de selección de "condición única y múltiples ramas". En comparación con la estructura de selección binaria if-else, será más concisa y clara en algunos casos.
Sin embargo, en Python, no podemos ver switch-case o estructura gramatical similar. ¿Por qué?
2. ¿Por qué no cambia el soporte de Python?
Hay una pregunta frecuente en el documento oficial que contiene esta pregunta: ¿Por qué no hay un cambio o una declaración de caso en Python?
FAQ significa Preguntas más frecuentes, que significa preguntas más frecuentes. La lista oficial de 27 preguntas más frecuentes está aquí: https://mp.weixin.qq.com/s/zabIvt4dfu_rf7SmGZXqXg
El documento ofrece varias sugerencias y nos dice varias alternativas de cambio / caso:
- Usar sentencia de juicio condicional if-elif-else
- Utilice un diccionario para asignar el valor del caso a la función llamada
- Use el getattr () incorporado para recuperar un método de llamada de objeto específico
Ha habido algunas propuestas (por ejemplo, PEP-275 y PEP-3103) que quieren introducir la sintaxis de cambio en Python, sin embargo, no hay consenso sobre " si y cómo realizar pruebas de rango ".
La prueba de alcance, o prueba de alcance, se refiere a varias pruebas para verificar el desempeño técnico de armas y municiones. Como los ensayos clínicos de drogas, es una prueba crítica antes de que se entregue el producto final.
La explicación del documento oficial de "Por qué Python no introduce el interruptor" en realidad proviene de la opinión de Guido van Rossum, el padre de Python, en PEP-3103:
Fuente: https://www.python.org/dev/peps/pep-3103
Una encuesta rápida durante mi presentación principal en PyCon 2007 muestra que esta propuesta no tiene apoyo popular. Por tanto, lo rechazo.
Hice una encuesta rápida en el discurso de apertura de PyCon 2007 y los resultados mostraron que esta propuesta no recibió un apoyo generalizado. Por eso lo rechacé.
En resumen, la propuesta de PEP está ahí, y la implementación gramatical tiene una forma rudimentaria, pero los desarrolladores centrales parecen no haber llegado a un acuerdo, lo que finalmente llevó al aborto de la propuesta.
3. ¿Qué dijeron PEP-275 y PEP-3103?
El PEP-3103 se propuso en 2006 y el PEP-275 se propuso en 2001. Lo que tienen en común es que plantearon una cierta necesidad de introducir declaraciones de cambio y analizaron varios esquemas de implementación alternativos. , El final es rechazado.
Fuente: https://www.python.org/dev/peps/pep-0275
Entonces, primero revisemos las discusiones que han hecho los desarrolladores principales y veamos qué pasaría si Python implementara la estructura del interruptor. (PD: PEP también incluye otro contenido, este artículo solo extrae la parte directamente relacionada con el cambio)
La estructura gramatical propuesta por PEP-275 es la siguiente:
switch EXPR: case CONSTANT: SUITE case CONSTANT: SUITE ... else: SUITE
La rama else es opcional, si no existe y las ramas anteriores no están satisfechas, no se hará nada. Además, la constante de valor de caso admite diferentes tipos, porque el tipo de expresión expr es dinámico.
PEP-275 también propone que el conmutador no admite el comportamiento de interrupción, es decir, cada rama de caso es independiente y completa, y no es necesario escribir interrupciones como en el lenguaje C.
El PEP también enumeró algunos otros problemas:
- Reutilice las palabras clave existentes sin introducir "cambiar" y "mayúsculas y minúsculas"
- Utilice nuevas palabras clave para evitar confusiones con el concepto de cambio de C
- Admite la selección de varios valores de una sola rama (por ejemplo: case'a ',' b ',' c ':…)
- También se recomienda admitir el juicio de valor de rango (por ejemplo: caso 10..14:…)
Además del esquema preferido, el PEP también registra varios esquemas gramaticales con diferentes estilos:
case EXPR: de CONSTANT: SUITE de CONSTANT: SUITE else: SUITE case EXPR: if CONSTANT: SUITE si CONSTANT: SUITE else: SUITE cuando EXPR: en CONSTANT_TUPLE: SUITE en CONSTANT_TUPLE: SUITE ... else: SUITE
PEP-275 registró muchas ideas y problemas importantes, que allanaron el camino para el surgimiento de PEP-3103.
Así que echemos un vistazo a lo que dice PEP-3103 escrito por Guido.
Primero reconoció las dos configuraciones básicas en PEP-275, por ejemplo, la realización de "ruptura implícita", para evitar que la rama del caso se caiga, lo que transfiere el control (otros lenguajes parecen requerir escritura explícita break); la rama else es opcional, reutilice la palabra clave else en lugar de introducir "default".
Guido está de acuerdo con el estilo promovido por PEP-275, pero también piensa que su problema son demasiados niveles de sangría. Por lo tanto, se recomienda reducir el número de espacios en la sangría de la rama de código. Por ejemplo, la sangría original es de 4 espacios y se cambia a la sangría 2. Espacios.
PEP-3103 también enumera otros tres esquemas de implementación, analiza sus diferencias y problemas, se omite el contenido específico, aquí es solo para mostrarle sus estilos:
# la rama del caso no tiene sangría cambiar EXPR: caso EXPR: SUITE caso EXPR: SUITE .... else: SUITE # Sin dos puntos después de la instrucción de cambio cambiar EXPR caso EXPR: SUITE caso EXPR: SUITE .... más: SUITE # omitido cambio de palabra clave de caso EXPR: EXPR: SUITE EXPR: SUITE ... else: SUITE
Además de la sintaxis básica, Guido dedicó mucho espacio a discutir la sintaxis extendida (Sintaxis extendida), es decir, la situación compleja de hacer coincidir múltiples valores en una rama de caso:
caso EXPR, EXPR, ...: # Guido 优选 的 caso en EXPR_LIST: caso * EXPR: caso [*] EXPR, [*] EXPR, ...: caso * (EXPR, EXPR, ...):
Las cuestiones clave que consideró incluyen: el caso en el que el resultado de la expresión en el conmutador es una tupla u objeto iterable, el caso en el que el valor del caso se trata como un desempaquetado de tuplas y la operación de asterisco "*" en la rama del caso ...
Luego, Guido dedicó mucho espacio a analizar cómo implementar el switch, las principales ideas discutidas en él son:
- Use la cadena if-elif equivalente para definir la declaración de cambio (se pueden hacer algunas optimizaciones)
- Igual que el anterior, además, todas las expresiones deben ser hash (hash)
- Piense en ello como un envío de diccionario precalculado (envío)
Hay mucho contenido en esta parte del PEP, porque Guido también considera varios caminos de implementación para cada idea, lo que llevó a su conclusión después de un análisis complejo: es demasiado pronto para decidir (es demasiado pronto para decidir ahora) temprano).
Después de leer PEP-3103, mi sensación general es: los pensamientos de Guido son muy divergentes y ricos en capas, pero carece de su percepción "rápida" cuando se enfrenta a otros problemas.
En otras palabras, entre las muchas soluciones posibles, se esfuerza por cubrir todo y, en última instancia, no puede convencerse a sí mismo de tomar una decisión dictatorial. La resistencia proviene principalmente de él mismo, no de los demás.
Sin embargo, la razón de esta situación puede estar relacionada con su posición predeterminada: parece pensar que "Python está bien sin una declaración de cambio", así que aunque escribió un PEP largo, solo está complicando el problema y cambiando El problema quedó en suspenso.
Al final, realizó una pequeña encuesta sobre PyCon, con la que rechazó "justificadamente" la PEP que inició, tratando de bloquear la boca pausada de todos ...
4. ¿Habrá declaraciones de cambio en el futuro?
En resumen, las razones por las que Python no tiene una declaración de cambio son las siguientes: los detalles de implementación / puntos de función del cambio no se han finalizado, es bueno sin un cambio y hay otras buenas formas de reemplazar la poca voluntad de cambio y Guido ...
Sin embargo, todavía tenemos que preguntarnos: ¿Habrá declaraciones de cambio en el futuro? ¿O una estructura de selección de múltiples ramas similar?
¿Por qué existe tal pregunta? La razón es que demasiados lenguajes tienen sus propias declaraciones de cambio, y muchas personas intentan escribir bibliotecas que proporcionan funciones de cambio (recuerdo haberlas visto dos veces en PyCoder's Weekly ).
A mí (el gato Python) no me gustó el cambio de principio a fin. Es casi seguro que Python no tendrá un cambio en el futuro. Sin embargo, es probable que introduzca una estructura gramatical más compleja similar a cambiar.
En junio de 2020 se propuso el PEP-622, que sugirió la introducción de la coincidencia de patrones en lenguajes como Scala, Erlang y Rust .
A octubre de 2020, el PEP se ha dividido en otros tres PEP (634-636), todos los cuales se encuentran actualmente en la etapa de borrador. Teniendo en cuenta la participación de los desarrolladores principales y las discusiones de temas, es más probable que estas propuestas se implementen en versiones futuras (como 3.10 en desarrollo).
Tomando una función promedio como ejemplo, la sintaxis de coincidencia de patrones se puede implementar de la siguiente manera:
def average (* args): match args: case [x, y]: # captura los dos elementos de una secuencia return (x + y) / 2 case [x]: # captura el único elemento de una secuencia return x case [ ]: return 0 case x: # captura la secuencia completa return sum (x) / len (x)
La estructura de caso de coincidencia es similar a la estructura de caso de cambio, pero se basa en un patrón en lugar de una expresión, por lo que hay más detalles a considerar y un espacio de aplicación más amplio.
Se recomienda a los lectores interesados en este tema que consulten estos nuevos PEP.
Finalmente, volvamos a la pregunta del título: ¿Por qué Python no admite la declaración de cambio?
El FAQ del documento oficial tiene una respuesta a esta pregunta, diciéndonos que hay varias buenas alternativas, y también dejó una pista: PEP una vez propuso la introducción de switch, pero no se implementó con éxito.
Siguiendo esta pista, este artículo desarmó los dos documentos PEP-275 y PEP-3103, mostrándote los diferentes estilos de soluciones de conmutador propuestas en la comunidad de Python, así como muchos temas pendientes.
Finalmente, también hemos prestado atención a las últimas dinámicas de PEP-622. ¡Parece que se espera que la sintaxis de coincidencia de "hermano gemelo" de switch se introduzca en Python! La discusión sobre el tema del cambio parece estar terminando, ¡pero hay otro tema más amplio en curso!