[Python-Dev] Can Python implementations reject semantically invalid expressions?

Guido van Rossum guido at python.org
Fri Jul 2 19:44:05 CEST 2010


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)


More information about the Python-Dev mailing list