[Python-Dev] Can Python implementations reject semantically invalid expressions? (original) (raw)

Cesare Di Mauro cesare.di.mauro at gmail.com
Fri Jul 2 19:50:55 CEST 2010

2010/7/2 Guido van Rossum <guido at python.org>

On Fri, Jul 2, 2010 at 10:28 AM, Nick Coghlan <ncoghlan at gmail.com> wrote: > On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro <craigcitro at gmail.com> wrote: >>> "1/0" is much faster to type than "raise SomeError" and serves the same >>> purpose sometimes for debugging purposes. Let's not forget that not >>> all code is written for eternity :) >>> >> >> Doesn't "raise" do the same thing for just two extra characters? > > No, raise on its own is only valid in an exception handler. Writing > "1/0" is at least somewhat common as an idiom for forcing a > ZeroDivisionError in examples and in test harnesses (I know I have > used it for both of those things many times). > > Given the diverse range of uses Python is put to, moving things from > runtime to compile time can definitely have significant unexpected > consequences (hence why many of us would be hesitant to consider an > implementation that made such changes to be an actual Python > implementation).

+1 on not changing this. For one, this will most likely break a large amount of 3rd party and stdlib software -- there are tons of statements like this that are practically unreachable or intentional. Second, I don't think it's going to make the kind of difference the OP is thinking of. Since Python is totally dynamic, and doesn't have macros, the only cases that would be caught would be things you are unlikely to type by accident -- like 1/0 or 1+"1". In other languages that have this behavior, there is usually a benefit where the arguments involved are variables whose type is known to the compiler, so it will catch things like (simple C example) #define FOO 0 main() { printf("%d\n", 1/FOO); } However the equivalent Python FOO = 0 def main(): print 1/FOO cannot be rejected at compile time because there is insufficient evidence that the value of FOO won't be changed before main() is called. I even reject the substitution of "raise ZeroDivisionError" for "1/0" since (a) nobody cares about such an optimization, and (b) it would break introspection and invalidate tests. (We have a long history of constant propagation in expressions causing subtle bugs. This could be worse.) -- --Guido van Rossum (python.org/~guido)

from future import compile_checks

Cesare Di Mauro -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20100702/f185c4aa/attachment.html>

More information about the Python-Dev mailing list