Precedente del operador de Python

Question

Python dice que * y/tienen la misma precedencia.
Sé que las expresiones en python se evalúan de izquierda a derecha.

puedo confiar en que y asumir que j j/m es siempre igual a (j j)/m evitando los paréntesis?
Si este es el caso ¿puedo suponer que esto se aplica a los operadores con la misma precedencia en general?

---

PS: La pregunta, ya que está muy bien para mis propósitos, que llegué a ella, mientras que la lectura de número entero de sólo código (como el ejemplo anterior) sin paréntesis, que en el momento parecía mucho sospechoso para mí .

Answer 1

Sí: diferentes operadores con la misma precedencia son asociativos de la izquierda; es decir, se operarán los dos objetos más a la izquierda, luego el resultado y el 3er artículo, y así sucesivamente.

Una excepción es el operador **:

>>> 2 ** 2 ** 3 
256 

Además, los operadores de comparación (==, >, etcétera) no se comportan de una manera asociativa, pero en lugar de traducir x [cmp] y [cmp] z en (x [cmp] y) and (y [cmp] z).

Answer 2

Respuesta corta: sí.

Los Python documentation says the following:

Los operadores en la misma caja tienen la misma prioridad. A menos que se proporcione explícitamente la sintaxis, los operadores son binarios. Operadores en el mismo grupo de cuadro de izquierda a derecha (excepto para las comparaciones, incluidas las pruebas, que tienen la misma precedencia y cadena de izquierda a derecha ... y la exponenciación, que se agrupa de derecha a izquierda).

Así, en otras palabras, la respuesta a su pregunta es sí, los operadores con la misma precedencia se grupo de izquierda a derecha, aparte de Comparisions which chain rather than group:

>>> x = 0 
>>> y = 0 
>>> x == y == True 
False 
>>> (x == y) == True 
True 
>>> x == (y == True) 
True 

y exponentation:

>>> 2 ** 2 ** 3 
256 
>>> (2 ** 2) ** 3 
64 
>>> 2 ** (2 ** 3) 
256 

también , en la asignación, el lado derecho se evalúa antes del lado izquierdo:

>>> x = 1 
>>> y = x = 2 
>>> y 
2 

Answer 3

Pero, si es ambiguo para usted, el codificador, y debe ser porque tiene que preguntar, entonces espere que sea al menos tan ambiguo para el lector y desperdicie un par de octetos para mayor claridad.

Confiar en las reglas de prioridad es genial si usted es un compilador.

añaden las respuestas a los comentarios:

Para la persona de código que se encuentra con una ambigüedad que requiere la consulta fuera para el aseguramiento de la lectura, se debe asumir que el lector siguiente será menos inteligente que tú y los guarda el esfuerzo y error humano evitable de analizar el mismo constructo y agregar el paréntesis para ellos.

Ocurre que incluso la respuesta aceptada era incorrecta (por razones, no tiene efecto, mira su primer comentario) de la que no tenía conocimiento y tampoco una fracción de los que la votaron por encima.

En cuanto a la afirmación sobre el álgebra básica, el ejemplo particular utilizado en el OP es instructivo. Independientemente de la precedencia del operador, la expresión j * (j/m) es algebraicamente idéntica a (j * j)/m. Desafortunadamente, el álgebra de Python es solo una aproximación del álgebra "ideal platónico" que podría arrojar respuestas incorrectas para cualquiera de las formas dependiendo de las magnitudes de j y m. Por ejemplo:

>>> m = 1e306 
>>> m 
1e+306 
>>> j = 1e307 
>>> j 
9.9999999999999999e+306 
>>> j/m 
10.0 
>>> j*j 
inf 
>>> j * (j/m) 
1e+308 
>>> (j * j)/m 
inf 
>>> ((j * j)/m) == (j * (j/m)) 
False 

Así que de hecho la propiedad de identidad de Python (y mi FPU) cuasi-álgebra no se sostiene. Y esto puede ser diferente en su máquina para que los documentation notes: números de punto

flotantes se implementan utilizando doble en C. Todas las apuestas en su precisión están apagados a menos que suceda a conocer la máquina que está trabajando .

Podría decirse que uno no tiene negocios que trabajan en el borde peluda de desbordamiento, y eso es cierto hasta cierto punto, pero retirado del contexto, la expresión es indeterminada dado una orden de operaciones y "correcta" en virtud de otro.