ANNOUNCE: A Python 2.1 release candidate!
Tim Peters
tim.one at home.com
Sat Apr 14 18:54:51 EDT 2001
[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.
More information about the Python-list
mailing list