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

[Cesare Di Mauro]

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>