Alternate numeric proposal

[Jeff Shannon]

Chris Gonnerman wrote:

> Why don't we add a hook to Python to control the numeric evaluation
> rules directly?
>
> An object containing methods to handle numerical operations would
> be registered with a statement like this:
>
>     __builtins__.numerics = MyNumericObject()
>

Not too bad of an idea, perhaps... but, if we allow this to be done on
the module level, then how is it different from  "from __future__ import
division" ??  The only difference being that, in the latter case, the
implication is that the distinction (old v. new division) will
eventually disappear.

I'm not too thrilled about the division change, but... Guido's
rationale, now that I've seen it, *is* consistent.  He wants, in
essence, to create a generic "number" type that switches internal
representation between ints, longs, floats, and complex as needed.  If
you're looking at ints as a special subclass of floats, then the
proposed semantics make sense.  If you look at ints as a separate set,
representing purely discrete quantities, then it doesn't.  Given that
automatic type conversions already treat ints in the former way, it
could be difficult to make a compelling argument against
float-division.  And he *does* seem to be taking the code-breakage issue
seriously... so, while I'd prefer  /  to retain its current meaning, I
guess I can accept the change.  Fortunately *I* don't have a large
library of scripts to modify....

My one big recommendation in this issue, would be that, however many
versions are released before float division becomes the default, that
version--the code-breaking version--be called Python 3.0.  This major of
a change in core behavior seems to indicate a major-version change.  I
suspect this would also help with the PR aspect of code breakage--it's
much easier to justify breaking old code with a major release than a
minor release, and there's less likelyhood of someone upgrading to a new
major version without at least checking the release notes--which, I
would expect, would prominently declare that this release would create
problems with legacy code.

Jeff Shannon
Technician/Programmer
Credit International

P.S.  I *was* going to suggest that if case-blindness were to be
accepted, that it be planned to become effective in the same release,
thus having only one major code-breaking release instead of two, but
fortunately, case-blindness seems to have been dropped and case
sensitivity will remain as is (whew!).