ANNOUNCE: A Python 2.1 release candidate!
gzeljko
gzeljko at sezampro.yu
Sat Apr 14 17:55:41 EDT 2001
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
> --
More information about the Python-list
mailing list