Re: [Pyunit-interest] comments on PyUnit

[Chuck E. <ec...@mi...>]

At 04:37 PM 4/23/2001 +0200, Steve Purcell wrote:
>Guido van Rossum wrote:
> > I'll admit that -O is pretty bogus, but I really don't think that
> > "assertions disabled" and "generating optimized code" should be tied
> > forever to each other (just because they were once in C).  Once we
> > have a decent optimizer, I can certainly see providing more control
> > over code generation options.
>
>I imagine that adding more command line switches for such variable
>optimisations would not be a benefit to the average user. I've never even
>seen any Python program that usually runs under '-O'.  I imagine such beasts
>are rare; either Python is fast enough, or modules are re-written in C. '-O'
>doesn't add much in the way of middle ground.

Currently. But presumably a future version of Python could work much harder 
under a -O directive to produce a faster .pyo.


>I might be alone in thinking that one of the crappy things about Perl
>compared to Python is its plethora of command line switches, but I've never
>thought about Python's command line switches at all, and I'm happy about that.
>
>Wouldn't the best (and simplest) option be to define '-O' to mean
>'__debug__ == 0 and assertions are disabled', and let the interpreter
>take care of optimisation? Java works that way: it declares that 'final' and
>'private' methods *may* be optimised away, but allows the user no control
>of optimisation. (Other than offering a don't-blow-my-foot-off option
>'-nojit', of course.)
>
>If the interpreter needs to be told what optimisations to make by the
>user, there is something wrong, and opportunities are then rife for code to
>appear that *requires* certain optimisations. Next, there'd have to be
>pragmas, right?

I disagree. What kind of code are you writing that *requires* an 
optimization? Presumably an optimization is a change in code generation 
that results in exactly the same program semantics with (hopefully) faster 
execution.

Consequently, removing an assertion is not a pure optimization. My program 
will definitely behave differently without assertions because undesireable 
conditions will progress past a point that they otherwise would not have. 
Consequently, I won't be sure how my program will behave in such a 
situation. Most likely I'll just get an exception, but perhaps outside 
resources such as files or databases will be put in a state inconsistent 
with what my program expects.

Furthermore, I won't get the usual e-mails to "su...@my..." that 
say "There are no users defined in the database" with included information 
such as database name, user name, etc. Instead I'll get something like 
"IndexError" with a deep traceback.

Basically, if Python continues to couple -O with "disable assert", then I 
will never be able to use -O even in production, because the performance 
gain of removing assert is practically nothing and the value of catching 
errors early is substantial.

If currently -O doesn't provide much performance gain, then I guess it's 
not a big deal. But if a future version does, then I will want to use it 
while keeping my asserts.


-Chuck