int/long unification hides bugs

[kartik]

> The question is how small is small? Less than 2**7? Less than 2**15? 
> Less than 2**31? Less than 2**63? And what's the significance of powers 
> of two? And what happens if you move from a 32 bit machine to a 64 bit 
> one? (or a 1024 bit one in a hundred years time?)

less than 2**31 most of the time & hardly ever greater than 2**63 - no
matter if my machine is 32-bit, 64-bit or 1024-bit. the required range
depends on the data   u want 2 store in the variable & not on the
hardware.


>  > PEP 237 says, "It will give new Python programmers [...] one less
>  > thing to learn [...]". i feel this is not so important as the quality
>  > of code a programmer writes once he does learn the language.
> 
> The thing is, the int/long cutoff is arbitrary, determined soley by 
> implemetation detail. 

agreed, but it need not be that way. ints can be defined to be 32-bit
(or 64-bit) on all architectures.


> A much better idea is the judicious use of assertions.
> 
> assert x < 15000
> 
> Not only does it protect you from runaway numbers, it also documents 
> what the expected range is, resulting in a much better "quality of code"

such an assertion must be placed before avery assignment to the
variable - & that's tedious. moreover, it can give u a false sense of
security when u think u have it wherever needed but u've forgotten it
somewhere.

a 32-bit limit is a crude kind of assertion that u get for free, and
one u expect should hold for most variables. for those few variables
it doesn't, u can use a long.

-kartik