craigcitro@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
">

(original) (raw)

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

On Fri, Jul 2, 2010 at 10:28 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

> On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro <craigcitro@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