2010/7/2 Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org">guido@python.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On Fri, Jul 2, 2010 at 10:28 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro <<a href="mailto:craigcitro@gmail.com">craigcitro@gmail.com</a>> wrote:<br>
>>> "1/0" is much faster to type than "raise SomeError" and serves the same<br>
>>> purpose sometimes for debugging purposes. Let's not forget that not<br>
>>> all code is written for eternity :)<br>
>>><br>
>><br>
>> Doesn't "raise" do the same thing for just two extra characters?<br>
><br>
> No, raise on its own is only valid in an exception handler. Writing<br>
> "1/0" is at least somewhat common as an idiom for forcing a<br>
> ZeroDivisionError in examples and in test harnesses (I know I have<br>
> used it for both of those things many times).<br>
><br>
> Given the diverse range of uses Python is put to, moving things from<br>
> runtime to compile time can definitely have significant unexpected<br>
> consequences (hence why many of us would be hesitant to consider an<br>
> implementation that made such changes to be an actual Python<br>
> implementation).<br>
<br>
+1 on not changing this.<br>
<br>
For one, this will most likely break a large amount of 3rd party and<br>
stdlib software -- there are tons of statements like this that are<br>
practically unreachable or intentional.<br>
<br>
Second, I don't think it's going to make the kind of difference the OP<br>
is thinking of. Since Python is totally dynamic, and doesn't have<br>
macros, the only cases that would be caught would be things you are<br>
unlikely to type by accident -- like 1/0 or 1+"1". In other languages<br>
that have this behavior, there is usually a benefit where the<br>
arguments involved are *variables* whose type is known to the<br>
compiler, so it will catch things like (simple C example)<br>
<br>
#define FOO 0<br>
main() {<br>
printf("%d\n", 1/FOO);<br>
}<br>
<br>
However the equivalent Python<br>
<br>
FOO = 0<br>
def main():<br>
print 1/FOO<br>
<br>
cannot be rejected at compile time because there is insufficient<br>
evidence that the value of FOO won't be changed before main() is<br>
called.<br>
<br>
I even reject the substitution of "raise ZeroDivisionError" for "1/0"<br>
since (a) nobody cares about such an optimization, and (b) it would<br>
break introspection and invalidate tests. (We have a long history of<br>
constant propagation in expressions causing subtle bugs. This could be<br>
worse.)<br>
<font color="#888888"><br>
--<br>
--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)<br>
</font></blockquote><div><br></div><div>from __future__ import compile_checks</div><div><br></div><div>Cesare Di Mauro</div>