int/long unification hides bugs

[Jeremy Bowers]

On Wed, 27 Oct 2004 06:00:38 -0700, kartik wrote:

> Peter Otten <__peter__ at web.de> wrote in message news:<clngtp$tat$02$1 at news.t-online.com>...
>> kartik vaddadi wrote:
>> 
>> >> Overflow errors are not automated tests.
>> > 
>> > why not? they detect bugs.
>> 
>> According to that logic your users will be automated tests, too...
> 
> Sorry for the wrong terminology, but what all I meant was what
> overflow errors detect bugs without you having to write code for that.
> -kartik

I have been trying to figure out what you mean by "detect bugs" and
failing. Static compile-time typing proponents can at least make this
claim with a straight face because typing errors (that you don't use
language features to bypass) are caught at compile time and no user can
ever see them, as the executable program never exists.

Overflow errors occur at run time, and used to throw an exception. That is
*not* "detecting an error", that is "throwing an exception", which aren't
even close to the same thing. Python does its best to convert errors into
exceptions, but languages without exceptions are certainly not error free,
nor do all errors get successfully converted into exceptions. (I've
crashed my stock Python 2.3 before, on the gzip module. No exception, just
error.) 

You are saying that when an int goes to a long, you think it would be
better to throw an exception, and brutally terminate that line of
processing (thread, process, whatever), instead of successfully adding a
number. 

You have to understand, you're getting flack here because you are saying
"I think things would break less if they broke more." That statement is
not entirely indefensible, but when there's no reason for anything to
break in the first place it is an odd thing to say and requires a lot more
than raw assertion.

Let me put this another way: What program have you written where this was
a problem? If you have one, let's discuss it concretely; maybe there was a
better way to do things. If you don't have one, then again, don't hold
your breath expecting to convince anyone against years of experience and
with no concrete examples of why your rather silly claims might be true
even in some small domain. 

If you want to find Python theoretically repulsive, may I suggest the much
more popular complaints against duck typing, taking offense at the
syntactic significance of whitespace, the lack of OO purity because
"len" is a function and not a method and there's all this "self"
everywhere, or perhaps the most recent fad, bitching about double
underscore methods?