PEP0238 lament

[Duncan Booth]

Guido van Rossum <guido at python.org> wrote in news:cpzo9t80l7.fsf at cj20424-
a.reston1.va.home.com:

> Such a (hypothetical!) world is just as consistent, yet it does not
> guarantee that the type of the result of an operation is the same as
> that of the operands, if by type you mean the storage type (int, long,
> float etc.).
As I said in my previous post that will make Python a different language. 
This whole discussion reminds me of those training courses where you get 
told about the different stages of introducing change: at present most of 
the Python community is showing fear and denial. Give us time and we may 
get onto grudging acceptance or even enlightenment, but we won't admit that 
yet.

The question I have to ask myself is whether, if introduced to Python for 
the first time after it has unified numbers, I would be as likely to pick 
it up and say 'this is the language I have wanted all my life', as I did 
when I was first introduced to Python a few years back.

I can see that for some purposes, such as teaching programming, a unified 
number system will be wonderful, but I have worries that the further you go 
from the underlying implementation, the bigger opportunity there is to mess 
up bigtime. On the other hand, Python already goes a LOT further from the 
underlying machine than C/C++ and that is nothing but a good thing. but 
then I am a hacker at heart.

> 
> Also look at PEP 237, which proposes to unify ints and longs.  Would
> you really prefer your "consistency" and see 1000000 * 1000000 raise
> OverflowError because the result cannot be represented as a 32-bit
> int, or would you prefer to drop the "consistency" in favor of getting
> a result at all?
I would like to reserve the right to change my mind on this answer several 
times.

I think what I would prefer would be the consistency of getting an answer, 
combined with the ability to constrain the result in cases where it is 
important. Say I am trying to interact with an existing program that reads 
32 bit integers from a file. In this situation I tend to ignore the fact 
that some Python implementations already have 64 bit integers, and leverage 
the exception handling to prevent me accidentally trying to write out too 
large a value, or getting something truncated in the file. However, if all 
I am doing is working out my bank balance (!) then naturally I want the 
correct answer even if inflation has gone through the roof.

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.

-- 
Duncan Booth                                             duncan at rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?