2014-04-20 5 views
5

Quindi, in Python 2 era chiaro. Ma in Python 3 sono un po 'confuso.True, False, Nessuna parola chiave o built-in in Python 3?

>>> import builtins 
>>> dir(builtins) 
['ArithmeticError', 'AssertionError', 'AttributeError', 'BaseException', 'BlockingIOError', 'BrokenPipeError', 'BufferError', 'BytesWarning', 'ChildProcessError', 'ConnectionAbortedError', 'ConnectionError', 'ConnectionRefusedError', 'ConnectionResetError', 'DeprecationWarning', 'EOFError', 'Ellipsis', 'EnvironmentError', 'Exception', 'False', 'FileExistsError', 'FileNotFoundError', 'FloatingPointError', 'FutureWarning', 'GeneratorExit', 'IOError', 'ImportError', 'ImportWarning', 'IndentationError', 'IndexError', 'InterruptedError', 'IsADirectoryError', 'KeyError', 'KeyboardInterrupt', 'LookupError', 'MemoryError', 'NameError', 'None', 'NotADirectoryError', 'NotImplemented', 'NotImplementedError', 'OSError', 'OverflowError', 'PendingDeprecationWarning', 'PermissionError', 'ProcessLookupError', 'ReferenceError', 'ResourceWarning', 'RuntimeError', 'RuntimeWarning', 'StopIteration', 'SyntaxError', 'SyntaxWarning', 'SystemError', 'SystemExit', 'TabError', 'TimeoutError', 'True', 'TypeError', 'UnboundLocalError', 'UnicodeDecodeError', 'UnicodeEncodeError', 'UnicodeError', 'UnicodeTranslateError', 'UnicodeWarning', 'UserWarning', 'ValueError', 'Warning', 'ZeroDivisionError', '__build_class__', '__debug__', '__doc__', '__import__', '__loader__', '__name__', '__package__', '__spec__', 'abs', 'all', 'any', 'ascii', 'bin', 'bool', 'bytearray', 'bytes', 'callable', 'chr', 'classmethod', 'compile', 'complex', 'copyright', 'credits', 'delattr', 'dict', 'dir', 'divmod', 'enumerate', 'eval', 'exec', 'exit', 'filter', 'float', 'format', 'frozenset', 'getattr', 'globals', 'hasattr', 'hash', 'help', 'hex', 'id', 'input', 'int', 'isinstance', 'issubclass', 'iter', 'len', 'license', 'list', 'locals', 'map', 'max', 'memoryview', 'min', 'next', 'object', 'oct', 'open', 'ord', 'pow', 'print', 'property', 'quit', 'range', 'repr', 'reversed', 'round', 'set', 'setattr', 'slice', 'sorted', 'staticmethod', 'str', 'sum', 'super', 'tuple', 'type', 'vars', 'zip'] 
>>> import keyword 
>>> dir(keyword.kwlist) 
['False', 'None', 'True', 'and', 'as', 'assert', 'break', 'class', 'continue', 'def', 'del', 'elif', 'else', 'except', 'finally', 'for', 'from', 'global', 'if', 'import', 'in', 'is', 'lambda', 'nonlocal', 'not', 'or', 'pass', 'raise', 'return', 'try', 'while', 'with', 'yield'] 

vero, False e Nessuno sono presenti sia nel modulo di builtins e il modulo parole chiave. Allora come dovrei trattarli? Come classi incorporate o come parole chiave?

risposta

6

Sono parole riservate e valori predefiniti. Dal Python 3 What's New:

True, False, e None sono parole riservate. (2.6 ha applicato parzialmente le restrizioni su None)

Ciò significa che non è possibile utilizzarli come nomi, assegnando loro un valore diverso. Questo impedisce accidentalmente mascherare il built-in valori Singleton:

>>> True = False 
    File "<stdin>", line 1 
SyntaxError: can't assign to keyword 

vedere anche Guido van Rossum's history lesson on None, True and False:

ho ancora dimenticato di rispondere se nessuno/vero/falso sono letterali o parole chiave. La mia risposta è che sono entrambi. Sono parole chiave perché è così che il parser le riconosce. Sono letterali perché è il loro ruolo nelle espressioni e perché rappresentano valori costanti.

Con True, False e None classificato come parole chiave, il compilatore Python può effettivamente ottimizzare il loro utilizzo, dal momento che non è possibile (direttamente) associare nuovamente questi nomi Python li può cercare come costanti invece di variabili globali, che è più veloce.

Fino a Python 3.4 c'erano ancora alcuni casi d'angolo in cui il compilatore inviava una ricerca globale per questi oggetti, vedere issue 16619. Da Python 3.4 in poi il parser Python è stato esteso per produrre un nuovo nodo AST NameConstant per garantire che vengano trattati come costanti ovunque.

+0

Ma se 'None',' True' e 'False' sono ora parole chiave Python, perché tenerli nel modulo * builtins *? – ostrokach

+2

@ostrokach: i * nomi * possono essere parole chiave, ma devono comunque fare riferimento a oggetti reali. Quando si utilizza il nome, si desidera comunque che quel nome si risolva nell'oggetto. E perché rompere qualsiasi codice che abbia usato 'builtins.False' o' builtins.True' per bypassare uno shadowing locale? –

Problemi correlati