logicos - operadores relacionales en python
¿Por qué no hay operadores++ y-en Python? (17)
¿Por qué no hay operadores ++ y -- en Python?
¡Claridad!
Python es mucho sobre claridad y es probable que ningún programador adivine correctamente el significado de --a menos que haya aprendido un lenguaje que tenga esa construcción.
Python también trata mucho de evitar construcciones que invitan a errores y se sabe que los operadores ++ son fuentes ricas de defectos. Estas dos razones son suficientes para no tener esos operadores en Python.
La decisión de que Python utiliza la sangría para marcar bloques en lugar de medios sintácticos, como algún tipo de horquillado de inicio / final o marcado final obligatorio, se basa en gran medida en las mismas consideraciones.
Para ilustrar, eche un vistazo a la discusión sobre la introducción de un operador condicional (en C: cond ? resultif : resultelse ) en Python en 2005. Lea al menos el primer mensaje y el mensaje de decisión de esa discussion (que tenía varios precursores sobre el mismo). tema previamente).
Trivialidad: el PEP que se menciona frecuentemente en el mismo es el " PEP 308 de la Propuesta de extensión de Python". LC significa comprensión de lista , GE significa expresión de generador (y no te preocupes si te confunden, no son ninguno de los pocos lugares complicados de Python).
Creo que proviene del credo de Python que "explícito es mejor que implícito".
El operador ++ no es exactamente igual al operador + =. De hecho el resultado de ambos es igual pero los usos tienen alguna diferencia. Por ejemplo, puede usar el operador ++ en condicional ternario, para bucle, etc. pero no puede usar + =. En el fondo, sentimos la necesidad ++ y -, por esta razón.
Esto puede deberse a que @GlennMaynard está analizando el asunto en comparación con otros idiomas, pero en Python, haces las cosas de la misma manera. No es una pregunta de ''por qué''. Está ahí y puedes hacer las cosas con el mismo efecto con x+= . En El zen de Python , se da: "solo debe haber una forma de resolver un problema". Las opciones múltiples son grandes en el arte (libertad de expresión) pero pésimas en ingeniería.
La clase ++ de operadores son expresiones con efectos secundarios. Esto es algo que generalmente no se encuentra en Python.
Por la misma razón, una asignación no es una expresión en Python, por lo que se evita el uso de if (a = f(...)) { /* using a here */ } .
Por último, sospecho que los operadores no son muy consistentes con la semántica de referencia de Pythons. Recuerde, Python no tiene variables (o punteros) con la semántica conocida de C / C ++.
Mi comprensión de por qué python no tiene el operador ++ está siguiendo: Cuando escribes esto en python a=b=c=1 obtendrás tres variables (etiquetas) que apuntan al mismo objeto (cuyo valor es 1). Puede verificar esto usando la función id que devolverá una dirección de memoria de objeto:
In [19]: id(a)
Out[19]: 34019256
In [20]: id(b)
Out[20]: 34019256
In [21]: id(c)
Out[21]: 34019256
Las tres variables (etiquetas) apuntan al mismo objeto. Ahora incremente una variable y vea cómo afecta a las direcciones de memoria:
In [22] a = a + 1
In [23]: id(a)
Out[23]: 34019232
In [24]: id(b)
Out[24]: 34019256
In [25]: id(c)
Out[25]: 34019256
Puedes ver que la variable a ahora apunta a otro objeto como variables b c . Porque has usado a = a + 1 está explícitamente claro. En otras palabras, asigna completamente otro objeto para etiquetar a . Imagine que puede escribir a++ esto sugeriría que no asignó a la variable a nuevo objeto, sino que incrementó el antiguo. Todo esto es IMHO para minimizar la confusión. Para una mejor comprensión, vea cómo funcionan las variables de Python:
¿Es Python llamada por valor o llamada por referencia? Ninguno.
¿Python pasa por valor o por referencia?
¿Python pasa por referencia o pasa por valor?
Python: ¿Cómo paso una variable por referencia?
Entendiendo las variables de Python y la gestión de la memoria
Emulando comportamiento de paso por valor en python
No es porque no tiene sentido; tiene mucho sentido definir "x ++" como "x + = 1, evaluando el enlace anterior de x".
Si desea conocer la razón original, tendrá que navegar por las antiguas listas de correo de Python o preguntar a alguien que estuvo allí (por ejemplo, Guido), pero es bastante fácil de justificar después del hecho:
Los incrementos y decrementos simples no son necesarios tanto como en otros idiomas. No escribes cosas como for(int i = 0; i < 10; ++i) en Python muy a menudo; en cambio, haces cosas como for i in range(0, 10) .
Como no se necesita con tanta frecuencia, hay muchas menos razones para darle su propia sintaxis especial; cuando necesitas incrementar, += usualmente está bien.
No es una decisión sobre si tiene sentido, o si puede hacerse; lo hace, y puede hacerlo. Es una cuestión de si vale la pena agregar el beneficio a la sintaxis central del lenguaje. Recuerde, estos son cuatro operadores: postinc, postdec, preinc, predec, y cada uno de ellos debería tener sus propias sobrecargas de clase; todos necesitan ser especificados y probados; agregaría códigos de operación al lenguaje (lo que implica un motor VM más grande y, por lo tanto, más lento); cada clase que admita un incremento lógico debería implementarlas (además de += y -= ).
Todo esto es redundante con += y -= , por lo que se convertiría en una pérdida neta.
Para completar ya buenas respuestas en esa página:
Supongamos que decidimos hacer esto, prefijo ( ++i ) que rompería los operadores unarios + y -.
Hoy en día, el prefijo por ++ o -- no hace nada, porque permite al operador unario más dos veces (no hace nada) o unario menos dos veces (dos veces: se cancela a sí mismo)
>>> i=12
>>> ++i
12
>>> --i
12
Así que eso potencialmente rompería esa lógica.
Por supuesto, podríamos decir "Guido acaba de decidir de esa manera", pero creo que la pregunta es realmente sobre las razones de esa decisión. Creo que hay varias razones:
- Mezcla declaraciones y expresiones, lo que no es una buena práctica. Consulte http://norvig.com/python-iaq.html
- En general, alienta a las personas a escribir códigos menos legibles.
- Complejidad adicional en la implementación del lenguaje, que no es necesaria en Python, como ya se mencionó
Porque, en Python, los enteros son inmutables (int + + en realidad devuelve un objeto diferente).
Además, con ++ / - debe preocuparse por pre / post-incremento / decremento, y solo se necesita presionar una tecla más para escribir x+=1 . En otras palabras, evita una posible confusión a costa de muy poca ganancia.
Primero, Python solo es indirectamente influenciado por C; está muy influenciado por ABC , que aparentemente no tiene estos operadores , por lo que tampoco debería ser una gran sorpresa no encontrarlos en Python.
En segundo lugar, como han dicho otros, el incremento y la disminución son compatibles con += y -= ya.
En tercer lugar, el soporte completo para un conjunto de operadores ++ y ++ generalmente incluye el soporte de las versiones prefijo y postfijo de ellos. En C y C ++, esto puede llevar a todo tipo de construcciones "encantadoras" que parecen (para mí) estar en contra del espíritu de simplicidad y franqueza que Python abraza.
Por ejemplo, mientras que la instrucción C while(*t++ = *s++); Puede parecer simple y elegante a un programador experimentado, a alguien que lo aprende, es cualquier cosa menos simple. Agregue una combinación de incrementos y decrementos de prefijo y postfijo, e incluso muchos profesionales tendrán que detenerse y pensar un poco.
Siempre supuse que tenía que ver con esta línea del zen de python:
Debe haber una, y preferiblemente solo una, manera obvia de hacerlo.
x ++ y x + = 1 hacen exactamente lo mismo, por lo que no hay razón para tener ambos.
Simplemente fue diseñado de esa manera. Los operadores de incremento y decremento son solo accesos directos para x = x + 1 . Python generalmente ha adoptado una estrategia de diseño que reduce el número de medios alternativos para realizar una operación. La asignación aumentada es lo más parecido a los operadores de incremento / decremento en Python, y ni siquiera se agregaron hasta Python 2.0.
Soy muy nuevo en Python, pero sospecho que la razón se debe al énfasis entre objetos mutables e inmutables dentro del lenguaje. Ahora, sé que x ++ puede interpretarse fácilmente como x = x + 1, pero PARECE como si estuvieras incrementando en el lugar un objeto que podría ser inmutable.
Sólo mi conjetura / sentimiento / presentimiento.
Tal vez una mejor pregunta sería preguntar por qué existen estos operadores en C. Los incrementos y decrementos de llamadas de K&R son inusuales (Sección 2.8 página 46). La Introducción los llama "más concisos y, a menudo, más eficientes". Sospecho que el hecho de que estas operaciones siempre aparezcan en la manipulación de punteros también ha jugado un papel importante en su introducción. En Python, probablemente se decidió que no tenía sentido tratar de optimizar los incrementos (de hecho, acabo de hacer una prueba en C, y parece que el ensamblado generado por gcc usa addl en lugar de incl en ambos casos) y no hay aritmética de punteros; así que habría sido solo una manera más de hacerlo y sabemos que Python lo odia.
como lo entendí, así no pensarás que el valor en la memoria ha cambiado. en c cuando haces x ++, el valor de x en la memoria cambia. pero en python todos los números son inmutables, por lo tanto, la dirección que x apunta como todavía tiene x no x + 1. cuando escribes x ++, pensarías que x cambiar lo que realmente sucede es que x refrence se cambia a una ubicación en la memoria donde se almacena x + 1 o recrear esta ubicación si no existe doe.
Esta respuesta original que escribí es un mito del folclore de la computación : desmentido por Dennis Ritchie como "históricamente imposible" como se señala en las cartas a los editores de Comunicaciones de la ACM julio de 2012 doi:10.1145/2209249.2209251
Los operadores de incremento / decremento de C se inventaron en un momento en que el compilador de C no era muy inteligente y los autores querían poder especificar la intención directa de utilizar un operador de lenguaje de máquina que guardaba unos cuantos ciclos para un compilador que podría hacer un
load memory
load 1
add
store memory
en lugar de
inc memory
y el PDP-11 incluso admitía las instrucciones de "autoincrement" y "autoincrement deferred" correspondientes a *++p y *p++ , respectivamente. Consulte la sección 5.3 del manual si es horriblemente curioso.
Como los compiladores son lo suficientemente inteligentes como para manejar los trucos de optimización de alto nivel incorporados en la sintaxis de C, ahora son solo una conveniencia sintáctica.
Python no tiene trucos para transmitir intenciones al ensamblador porque no usa uno.