keywords functions python keyword

functions - ¿Por qué se cambiaron True and False por palabras clave en Python 3?



keywords python functions (3)

En Python 2, pudimos reasignar True y False (pero no None ), pero los tres ( True , False y None ) se consideraron variables integradas. Sin embargo, en Py3k los tres se cambiaron en palabras clave según los documentos .

Desde mi propia especulación, solo pude adivinar que era para prevenir travesuras como this derivadas de la vieja broma True, False = False, True . Sin embargo, en Python 2.7.5, y tal vez antes, las instrucciones como None = 3 que reasignaron None plantearon SyntaxError: cannot assign to None .

Semánticamente, no creo que True , False y None sean palabras clave, ya que al final son semánticamente literales, que es lo que Java ha hecho. Revisé PEP 0 (el índice) y no pude encontrar un PEP que explicara por qué fueron cambiados.

¿Hay beneficios de rendimiento u otras razones para convertirlas en palabras clave en lugar de literales o en mayúsculas especiales como None en python2?

Esto fue discutido hace algunos meses en python-dev. Tener toneladas de enlaces a la definición de True sería molesto, contrario a los enlaces a, por ejemplo, el documento no local o con las declaraciones.

Y las cosas concluyen por qué True and False hará las cosas "aún más finas".

  1. re-bound como un efecto secundario de funciones llamadas dentro del ciclo.

    Es realmente fácil de cambiar, como:

    def True(): print True

  2. Realmente no existe un buen caso de uso para permitir que el código de usuario vuelva a enlazar los nombres incorporados None, True y False, lo que hace que las palabras clave tengan casi solo ventajas.

  3. Hacer que el programa tenga que buscar "Verdadero" en la tabla de símbolos en cada paso solo para encontrarlo. Verdadero tiene un valor Verdadero está lejos de ser intuitivo. (Es por eso que 1 es más rápido que True).

    x = compilar (''while 1: foop ()'', '''', ''exec'')

    dis.dis (x)

    0 SETUP_LOOP 19 (to 22) 3 JUMP_FORWARD 4 (to 10) 6 JUMP_IF_FALSE 11 (to 20) 9 POP_TOP >> 10 LOAD_NAME 0 (foop) 13 CALL_FUNCTION 0 16 POP_TOP 17 JUMP_ABSOLUTE 10 >> 20 POP_TOP 21 POP_BLOCK >> 22 LOAD_CONST 1 (None) 25 RETURN_VALUE

x = compilar (''while True: foop ()'', '''', ''exec'')

dis.dis (x)

0 SETUP_LOOP 19 (to 22) >> 3 LOAD_NAME 0 (True) 6 JUMP_IF_FALSE 11 (to 20) 9 POP_TOP 10 LOAD_NAME 1 (foop) 13 CALL_FUNCTION 0 16 POP_TOP 17 JUMP_ABSOLUTE 3 >> 20 POP_TOP 21 POP_BLOCK >> 22 LOAD_CONST 0 (None) 25 RETURN_VALUE

referencia:

Conversación inicial relacionada con la asignación a Verdadero y Falso:

algunos datos auxiliares:

PD: algunos números muestran True / 1:

[alex@lancelot test]$ timeit.py -c -s''import itertools as it'' ''c=it.count()'' ''while True:'' '' if c.next()>99: break'' 10000 loops, best of 3: 91 usec per loop [alex@lancelot test]$ timeit.py -c -s''import itertools as it'' ''c=it.count()'' ''while 1:'' '' if c.next()>99: break'' 10000 loops, best of 3: 76 usec per loop

Por dos razones, principalmente:

  1. Entonces la gente no hace un __builtin__.True = False broma oculta en un módulo aleatorio. (como se muestra en devnull)
  2. Porque las palabras clave son más rápidas que las construcciones globales globales. En Python 2.x, el intérprete tendría que resolver los valores de esas variables antes de usarlas, lo que es un poco más lento que las palabras clave. (Consulte ¿Por qué es True más lento que si 1? )

Posiblemente porque Python 2.6 no solo permitía True = False sino que también permitía decir cosas graciosas como:

__builtin__.True = False

que restablecería True to False para todo el proceso. Puede llevar a cosas realmente divertidas sucediendo:

>>> import __builtin__ >>> __builtin__.True = False >>> True False >>> False False >>> __builtin__.False = True >>> True False >>> False False

EDITAR : Como señaló Mike , el wiki de Python también declara lo siguiente bajo Cambios del lenguaje central :

  • Realice palabras clave verdaderas y falsas.
    • Motivo: hacer que la asignación a ellos sea imposible.