ANNOUNCE: A Python 2.1 release candidate!

[gzeljko]

Looks clear to me.

-O    = Debuging is over, isn't it.

In perfekt world it would remove assignments to
__debug__ also.( = remove breakpoints)

ly-y'rs-gzeljko

Don O'Donnell <donod at home.com> wrote in message
news:3AD8A21D.34800DB9 at home.com...
>
>
> 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
> --