int/long unification hides bugs

[Josiah Carlson]

tweedgeezer at hotmail.com (Jeremy Fincher) wrote:
> 
> Cliff Wells <clifford.wells at comcast.net> wrote in message news:<mailman.5708.1099128187.5135.python-list at python.org>...
> > 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.

So seemingly you have a problem with:
    val = RangedInteger(int(user_provided), mylow, myhigh)

Ok, so you've got a problem with that.  *shrug*


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

Or any one of the other infinite values that binary floating point does
not represent exactly.  What you have done is to take your problem of
limiting range, and attempt to fold it into a type with a larger dynamic
range, but with limited precision.  Replacing an "OverflowError", with a
possible future infinite value returned by float and known precision
issues with non-integer math.

What gets me is that you seem to be saying that BEFORE 2.4 has
officially come out, you have switched to using floats because 2.4 will
remove the OverflowError when integers overflow.


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

Ah, but you, or anyone else, only needs to implement it once for some
class of things, and it is done.  People who want more or different
functionality are free to derive.  With a little bit of futzing, you
could take the base code given by Andrew Dalke, add in custom handlers
for binary exponentiation with __pow__, and you're basically done.

Is there anything stopping you from doing this other than laziness and a
desire to complain "Python 2.4 doesn't have functionality X that it
choose_one_or_more(used_to_have, that_i_want)"?


 - Josiah