<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 3/12/2011 12:39 AM, Eugene Toder wrote:
    <blockquote
      cite="mid:AANLkTimrr7Dy3xXeNe1tJb0vGvosJr8oHhxxxnMoY0En@mail.gmail.com"
      type="cite">
      <blockquote type="cite" style="color: rgb(0, 0, 0);">
        <pre wrap=""><span class="moz-txt-citetags">&gt; </span>You've got wishful thinking if you think a handful of tests can catch
<span class="moz-txt-citetags">&gt; </span>errors in code that sophisticated.
</pre>
      </blockquote>
      <pre wrap="">Why limit yourself with a handful of tests? Python is widespread,
there's <b class="moz-txt-star"><span class="moz-txt-tag">*</span>a lot<span class="moz-txt-tag">*</span></b> of code in Python. Unlike with libraries, any code you
run tests the optimizer, so just run a lot of code. And, as I've said,
write a test generator.
</pre>
    </blockquote>
    <br>
    As we're thinking about what the optimizer of the future should be,
    it would be great to have a way to turn it off completely.&nbsp; This
    would allow the tests to run test code both with and without the
    optimizer, and to verify that the two results were the same.&nbsp; Then
    we could automatically verify that the optimizer isn't changing
    semantics.<br>
    <br>
    BTW: I also believe it would be very useful to make the
    turn-off-the-optimizer switch available for users so they can run
    their code unoptimized for times when they are more interested in
    program analysis than in execution speed.&nbsp; See
    <a class="moz-txt-link-freetext" href="http://bugs.python.org/issue2506">http://bugs.python.org/issue2506</a> (closed 3 years ago) that I filed
    with this request.<br>
    <br>
    --Ned.<br>
  </body>
</html>