ANNOUNCE: A Python 2.1 release candidate!

[Don O'Donnell]

Tim Peters wrote:
> 
> Stuffing code blocks under "if __debug__" is also an intended use, although
> stuffing purely informative prints in those blocks probably isn't a good idea
> (see below).  I'd use, e.g., a vrbl named TRACE instead for tracing function
> entries and exits.

"informative prints", tracing function entries and exits, call it what
you will, it's all debugging to me.  And I like to be able to:
1. Turn it on and off at run time.
2. Completely eliminate it from the compiled code when compiled with
optimization.

> 
> > thus all debugging is under control of a single variable.
> >
> > I find it very useful to be able to assign to __debug__.  There are at
> > least two situations where I use it regularly:
> >
> > 1.  As a run-time debugging switch.  By providing an interactive user
> > option switch which sets __debug__ to 0 or 1 dynamically at run time
> > through user input (menu or command prompt).  This allows me to
> > easily turn off debugging when it's not needed and turn it back on
> > when it is.
> 
> Except that it doesn't work correctly for that:  if you (or your users) ever
> run Python with -O, your "if __debug__:" blocks vanish entirely, and then you
> can set __debug__ to 1 until you're blue in the face and it won't make any
> difference:

But that's precisely why I want to use __debug__ and not some other
variable such as TRACE.  When I'm ready to release production code to my
users, I compile it with the -O option and distribute the .pyc modules
without the overhead of all the debugging code.  Users shouldn't be
debugging my code anyway.  Even when I release the source code to
knowledgeable users, they can easily suppress unneeded debugging code
with the -O switch.

But while I'm testing (without the -O switch) I can use the __debug__
variable as a dynamic run-time switch to turn debugging on and of at
will. 

IT'S PERFECT, IT'S WONDERFUL, ITS JUST WHAT I WANT!  WHY WOULD ANYONE
WANT TO CHANGE SUCH AN EXCELLENT DESIGN?

To have to write:
    if __debug__:
        if DEBUG:
            print ...
seems awfully tedious.

> That's "a feature", btw:  __debug__ was designed so that the code under its
> control doesn't even get compiled under -O.  For example, from an interactive
> Python -O session:
> 
> >>> def f():
> ...     if __debug__:
> ...         print "hi"
> ...
> >>> import dis
> >>> dis.dis(f)
>           0 LOAD_CONST               0 (None)
>           3 RETURN_VALUE
> >>>
> 
> Note that there's no sign of the "if __debug__", or of the code block it
> controls, if the bytecode for f.  That's why runtime setting of __debug__ has
> no effect under -O.

I KNOW, THAT'S GREAT. I DON'T WANT IT THERE WHEN I COMPILE WITH THE -O
SWITCH.

> If you want a variable that won't make code go away by magic at compile time,
> define your own. 

I KNOW, BUT I DON'T.  I WANT IT TO GO AWAY.

> > Can anyone explain to me why this change, to make __debug__ read only,
> > is necessary or beneficial in some way?
> 
> Because assignment to __debug__ was never intended, and, as above, that
> assignment under -O "doesn't work" keeps surprising people, despite that
> its -O behavior was a key design goal.

It seems to me that removing such an excellent feature from the language
because it surprises some people is very wrong.  Wouldn't it be better
to try to educate people about its use, perhaps by improving the
documentation.  Heck, if it will help to keep __debug__ bindable, I'll
even volunteer to write the docs myself.  It really doesn't seem that
complicated -- 

"If you compile with the -O option the built-in variable __debug__
behaves as though it is permanently assigned the value 0.  Attempts to
change it are ignored. ..."

A recent posting to this NG concerned the surprising effect of
extraneous commas in a list comprehension. But when studied carefully in
the light of the excellent Language Ref Manual, its behaviour was
exactly as expected.  Are we to assume that this "surprising" behaviour
also needs to be "corrected" by changing the semantics of the list
comprehension.  I sincerely hope not. 

PLEASE DON'T DUMB DOWN PYTHON... IT'S SO BEAUTIFUL AS IT IS!

> > Or am I misinterpreting GvR's statement that "assignment to
> > __debug__ ... will become illegal in 2.2."
> 
> Nope, he meant it.  Starting in 2.1, you'll get a Syntaxwarning msg whenever
> you try to bind __debug__:
> 
>     SyntaxWarning: can not assign to __debug__
> 
> In 2.2, it will become a SyntaxError instead.
> 
How sad.

-don