"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
It is unlike to before Py3.0. Making them constants would break the reams of compatability code: True, False = (1==1), (1!=1).
I don't see why that particular statement needs to fail. The interpreter could permit assigning True=True or False=False without raising an error. Then True and False wouldn't really be constants, but they'd instead be variables whose value was always known to the compiler, which for optimization purposes is just as good. The compiler could alternatively do some simple dataflow analysis to make sure the values of True and False haven't been changed in a particular module, before doing that particular optimization.
Until this code:
.>>> import pdb .>>> pdb.True = 0 .>>> pdb.x = "Darn writeable module dictionaries" .>>> from pdb import True .>>> True 0 .>>> from pdb import x .>>> x 'Darn writeable module dictionaries'
is illegal, the compiler is really limited in what it can safely assume about the contents of module dictionaries. There's such a thing as being *too* flexible - and in this case, the flexibility eliminates some potential optimisations (in this case, "I know what this is" compile time name binding).
I believe modifying a module's globals dictionary from outside the module is in the process of being deprecated - the catch is that distinguishing it from some legitimate accesses to a module's globals is not straightforward.
Cheers, Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list
