PEP0238 lament

[Daniel Fackrell]

"Guido van Rossum" <guido at python.org> wrote in message
news:cpzo9t80l7.fsf at cj20424-a.reston1.va.home.com...
> Duncan Booth <duncan at NOSPAMrcp.co.uk> writes:
>
> > I agree that it would make Python a different language. Neither better
nor
> > worse.
> >
> > You arguably gain in meeting some peoples expectations of the division
> > operator, but you lose consistency in that previously (as far I can
think),
> > the operators +, -, *, /, % when given two arguments of the same numeric
> > type always return a result of that same type. In future we have to be
> > prepared to explain to beginners that division can give a result of a
> > different type: in fact you cannot even predict the type of the result
when
> > you know the types of the arguments, you have to know their values as
well.
>
> In a farther future, when PEP 228 is fully implemented, Python may
> only have *one* (built-in) numeric type, "number".  Then all
> operations will defined entirely on the mathematical value, and the
> different "types" as we know now are merely details of storage
> efficiency -- except that numbers will also have an indication of
> "exactness" or "approximateness", to acknowledge the fact that the
> number system may choose to give approximate results for some
> operations.  We may end up deciding that rationals have too many
> problems, and replace binary floating point with decimal floating
> point to address a different set of confusions, and so maybe division
> of two exact numbers may not always yield an exact result -- just like
> the square root of 2 is conventionally calculated only to a limited
> precision.  Or we may choose to represent rationals exactly -- in any
> case, 1/2==0 will be false, just as PEP 238 proposes.
>
> 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.).
>
> 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?
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)

Would this unified number system somehow still be able to provide the
functionality that ints provide with regard to bitwise operations?  There
may be other problems that arise as well, but I'm too much of a newbie to
point them out at this time.
--
Daniel Fackrell (dfackrell at linuxmail.org)
When we attempt the impossible, we can experience true growth.