int/long unification hides bugs
tweedgeezer at hotmail.com
Sat Oct 30 17:32:37 CEST 2004
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".
> 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
> 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.
More information about the Python-list