proposed language change to int/int==float (was: PEP0238 lament)

[Guido van Rossum]

[Ken Seehof, on the new numeric system]
> This scares me.  The whole numeric unification thing seems to be hiding
> all the intrinsically difficult properties of numbers.  Kind of like Windows
> ME trying to hide all the intrinsically difficult properties of computers.

But that's what Python is trying to do anyway -- hide all the
uninteresting complications, like word size, byte order, memory
allocation, data types...

> Hiding difficult properties usually makes those properties more difficult
> in the long run, while appeasing beginners in the short run.  This is not
> a good trade off.

The fact that you like Python so much suggests otherwise, if the
hiding is done right.

> Here's some questions that come to mind that have a "sweep the can
> of worms under the rug" theme:
> 
> 1. If inexact numbers are excluded from being used as sequence indices,
> won't there be a tendency for programs to have more special case bugs?
> The value of a variable in a calculation might be usually exact, but inexact
> once in awhile.  So floats can be used as indices until there is a precision
> error?  Yikes!  And I have a funny feeling in my stomach that this is just
> the tip of the iceberg.  Floats may or may not turn out to be exact
> depending
> on details of a particular run.  This is a Bad Thing.  Integers are always
> exact.  This is a good thing.

Assuming we'll adopt a variation of Scheme's numerical tower (which
I'm currently in favor of, more or less), this won't happen.  Floats
and complex would always be considered inexact (and ints and rationals
exact), and inexact numbers are not allowed as sequence indices, even
if their exact value is an integer.

In fact, the rules won't change much: 1000000*1000000 will return
1000000000000 rather raising an OverflowError, and *maybe* (that is
still to be decided) 1/2 will return a rational instead of a float,
but 

> 2. Wouldn't a function in an extension module that takes a number as an
> argument be significantly more difficult to write, since it would have
> figure out the actual runtime type of the number and deal with all the
> different cases?  Right now, I just have to verify the type.  Seems like
> even if you somehow solve the problem of breaking python code, you
> will break extension code badly.  One thing I like about python is that
> it is highly compatible with its extension language.  The further we get
> from the current symmetry between python and C/C++ the harder it
> will be to write extensions.  The same goes for case sensitivity BTW.

Have you written many extension modules?  Getting an argument
typically specifies the desired C type, and PyArg_ParseTuple()
converts the Python object to the right value, or raises an
exception.  This mechanism already accepts multiple types, and you
won't have to change a thing.

> 3. Why do you expect it to be wise to hide all the numeric issues under
> a level of abstraction?  The issues will still exist, but will just be more
> obscure.  Right now, we have a simple and explicit numeric system with
> simple and well understood problems.  Trying to make it simpler for
> beginners by adding complexity to the overall system won't work.

Most of the issues I plan to hide are simply nuisances, not inrinsic
complications.  Float arithmetic will work exactly as before, except
maybe we'll call it inexact arithmetic.  Int arithmetic will work
exactly as before, except you won't have to worry about overflow.

> The basic fact is that all conceivable numeric systems suck badly
> for different reasons, (including the one we currently have).  And
> for every problem there is a solution that's even worse.  Just keep
> what we have.  It sucks less badly than all of the alternatives.
> Even the / operator has it's virtues.  It make integers a closed set
> with respect to all the basic operators.  This is a Good Thing.

Here opinions differ.

> The grand unification of numbers is the other way to try to create a
> closed set, so it's not surprising that the 1/2 debate eventually
> lead to it.  But it won't work because the different kinds of
> numbers really are different and trying to stuff them into the same
> set is inherently unnatural.  I'd accept 1/2 == 0.5 with 1//2 == 0
> as the integer quotient operator, but going further than that is a
> mistake IMHO.

Sounds like FUD to me.  Wait until we have worked out the real
proposal.  In the mean time, look at Scheme's rules: 

http://www.swiss.ai.mit.edu/ftpdir/scheme-reports/r5rs-html/r5rs_8.html#SEC50

> Kinda-weird-that-computers-are-so-lousy-at-dealing-with-numbers-ly yrs,

Wait till you rely on them for dealing with words. :-)

> "Things should be made as simple as possible -- but no simpler."
> - A. Einstein

That has always been Python's unofficial motto, and it's not going to
change.

I hate to say "trust me" because I don't know why you should, but I
really do mean it.  Trust me.

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