> >> None is moving slowly toward becoming a true constant. Perhaps the > >> same should be true of True and False. > > Guido> Problem with this is that there's currently lots of code out > Guido> there that was recently modified to read > > Guido> try: > Guido> True > Guido> except NameError: > Guido> True = 1 > Guido> False = 0 > > Guido> That would become a syntax error if True/False were true > Guido> constants. :-( > > Hmmm... Those code blocks would only be executed on older versions of the > interpreter. Is there some way to use that knowledge to finesse the > problem? It would be a real hack, but if the compiler recognized precisely > the above construct (or at least assignment in an except block guarded by > NameError), it could shut up about the assignment. You would have to do a fairly significant analysis of all code in the module to know that there are no assignments to globals True or False anywhere, *and* you would have to add a heuristic to cope with the very code fragment above, *and* you would have to have a firm belief that no other code would do import foo foo.True = "True" I've often mentioned the first item above (per-module code analysis) as doable, but it's not done. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4