ANNOUNCE: A Python 2.1 release candidate!

[Tim Peters]

[Don O'Donnell]
> "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.

As you showed later, you already know how to do this without assigning to
__debug__.

> ...
> 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.

Can only repeat that it was never intended that you be able to assign to
__debug__:  Guido views this change as fixing an old bug.  Note that you use
__xxx__ names at your own risk, in the absence of docs explicitly blessing
the uses you make of them, and nothing in the docs said you could change
__debug__'s value at runtime.  The 2.1 docs explicitly say you cannot (as was
always Guido's intent).

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

Explained in the last reply.  I understand you're not satisfied with the
explanation, but that doesn't mean I'm hiding a better one that can only be
coaxed into the open VIA SHOUTING <wink>.

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

Then design and sell a better facility.  Many have been suggested in the
past, and __debug__ is a minimal gimmick that got in as part of the assert
implementation.  Here's Guido's original design note, in the midst of a long
thread with *lots* of interesting suggestions:

    http://groups.yahoo.com/group/python-list/message/19647

> ...
> It seems to me that removing such an excellent feature from the
> language because it surprises some people is very wrong.

You were using an undocumented accident that was never intended.  To call
this "removing a feature" is thus absurd in most senses, but quite
understandable in the only sense you care about <wink>.  I'm happy that Guido
takes a larger view of it, though.

> ...
> 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.

I don't see a way to make time for it myself, but, yes, I'd like to tighten
the *syntax* of listcomps here.  The example was indeed very surprising, to
both newbies and experts.  That sucks.  Note that the prototype listcomp
implementation originally allowed stuff like

    [i, i for i in range(5)]

too.  That also made "exactly as expected" sense from a legalistic POV.  But
it's a strained view, and the syntax of listcomps was tightened to require
parens around tuple targets.  It's considerably clearer even to the
experienced eye to force that one to be spelled:

    [(i, i) for i in range(5)]

instead, and 2.0 does require that spelling.  No functionality was lost.  It
would make similar good sense to require spelling

    [(i, i) for i in range(5),]

as

    [(i, i) for i in (range(5),)]

for those people who truly want the

    [([0, 1, 2, 3, 4], [0, 1, 2, 3, 4])]

result.  For everyone else, we've almost certainly changed a typo into a
logic error by allowing the former spelling.  Again, no functionality would
be lost.

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

Make it smarter, then, by reviving the debate about truly *good* debugging
facilities.  The __debug__ gimmick is minimal, feeble and hard to build on
(esp. now that the implementation is changing to match its design).  You seem
to have a two-state "everything or nothing" notion of what constitutes good
debugging support; over the long term I'll be glad if enforcing the read-only
nature of __debug__ now irritates people enough to dream up richer
mechanisms.  I doubt Guido has that in mind, though.