int/long unification hides bugs

[Jeremy Fincher]

Cliff Wells <clifford.wells at comcast.net> wrote in message news:<mailman.5708.1099128187.5135.python-list at python.org>...
> 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?

Accepting integer equations from untrusted users and evaluating them. 
That's my exact use case, in fact.

> It seems to me that whether an OverflowError occurs is
> only one way of determining whether a computation is bounded,

It's not really a way of *determining* whether a computation is
bounded, but *guaranteeing* that it is bounded.  What I eventually did
was simply convert all numbers to floats, and do my calculations with
those; but this results in some ugliness, for instance, when a user
asks for the value of "10**24".

> 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).

They're also significantly more complex and significantly less
portable.

> 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.

That's exactly it.  With bounded integers, I know for sure that my
program can perform a calculation in a reasonable time without
exhausting the resources of the machine.  Without them, I have to go
to great lengths to receive that assurance.

Jeremy