<!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">> </span>You've got wishful thinking if you think a handful of tests can catch
<span class="moz-txt-citetags">> </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. 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. 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. 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>