PEP0238 lament

[Guido van Rossum]

Duncan Booth <duncan at NOSPAMrcp.co.uk> writes:

> I guess what I am saying is that unifying numbers is fine, and I have no 
> gripe with a language that says that 1, 4.13, and 5+7j are all the same 
> basic type, but if that is all it has then it won't always be my first 
> language of choice. Add in a module or two to support explicit machine 
> types so I can write: x = int32(1) or whatever and those of us who need 
> overflow exceptions can always get them when we need them. Actually it now 
> occurs to me that what I would probably *really* like would be a general 
> constrained numeric type so I could do things like:
>     	Rating = constrainedinteger(0, 100)
>     	old = Rating(95)
>     	new = old * 2 # Throws OverflowError
> but using it sparingly and with caution.

I don't see when a unified number system would ever be less convenient
than the current number system, *except* in the rare case where you
are transliterating an algorithm from C that depends on integer size.
Unsigned ints of n bits are easily emulated by taking all results
modulo 2**n -- I do this now using Python long ints when I need to
emulate unsigned C longs.

Using the new type/class unification in Python 2.2, you will be able
to subtype the int or long types easily to create your own constrained
types.

--Guido van Rossum (home page: http://www.python.org/~guido/)