int/long unification hides bugs

Cliff Wells clifford.wells at
Sat Oct 30 11:23:02 CEST 2004

On Thu, 2004-10-28 at 08:09 -0700, Jeremy Fincher wrote:

> The problem with int/long unification is that there is no simple
> pure-Python alternative for those of us who need a bounded integer
> type.  If our code depended on that raised OverflowError in order to
> ensure that our computations were bounded, we're left high and dry
> with ints and longs unified.  We must either drop down to C and write
> a bounded integer type, or we're stuck with code that no longer works.

Color me ignorant (I still maintain that numbers were a bad idea to
start with), but can you give an example of something that would
*require* this?  It seems to me that whether an OverflowError occurs is
only one way of determining whether a computation is bounded, and
further, it's a rather arbitrary marker (it is disassociated from the
capabilities of the computer hardware it's run on) .  I'd think
computational resources are the real concern (time and memory).  These
can be handled other ways (e.g. running the computation in a separate
process and killing it if it exceeds certain time/memory constraints).

I suppose my position is this: if I have a computer that can perform a
calculation in a reasonable time without exhausting the resources of the
machine then I would think that Python shouldn't try to stop me from
doing it, at least not based on some arbitrary number of bits.


Cliff Wells <clifford.wells at>

More information about the Python-list mailing list