2010/7/2 Guido van Rossum <gu...@python.org>
> On Fri, Jul 2, 2010 at 10:28 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> > On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro <craigci...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
