Guido van Rossum wrote:
... So anybody porting to Python 2.1 will essentially have to remove all __debug__ blocks that were previously disabled by assigning 0 to __debug__. I think this is undesirable.
Assigning to __debug__ was never well-defined. You used it at your own risk.
As I recall, in the original description of __debug__, being able to assign to it was reported as one of its main features, so that you still had a run-time option (unless the interpreter was running with -O, which eliminates the __debug__ blocks).
The manual has always used words that suggest that there is something special about __debug__. And there was: the compiler assumed it could eliminate blocks started with "if __debug__:" when compiling in -O mode. Also, assert statements have always used LOAD_GLOBAL to retrieve the __debug__ variable.
So in short, I think this change should be reverted.
It's possible that it breaks more code, and it's possible that we end up having to change the error into a warning for now. But I insist that assignment to __debug__ should become illegal. You can *use* the variable (to determine whether -O is on or not), but you can't *set* it.
Regards, Martin
P.S. What was the motivation for that change, anyway?
To enforce a restriction that was always intended: __debug__ should be a read-only variable.
So you are suggesting that we change all our code to something like: __enable_debug__ = 0 # set to 0 for production mode ... if __debug__ and __enable_debug__: print 'debugging information' ... I don't see the point in having to introduce a new variable just to disable debugging code in Python code which does not run under -O. What does defining __debug__ as read-only variable buy us in the long term ? -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/