[Python-Dev] Revamping Python's Numeric Model

[Guido van Rossum]

> [Guido]
> > That's your choice.  Wildly inaccurate is sometimes unavoidable.  This
> > is clearly an issue open for debate, but note that I speak from
> > experience: ABC used rationals unless you forced it to use reals, and
> > the rationals *did* cause real users to complain about how slow ABC
> > was.

[Moshe]
> Well, experiences differ. I'm on the Scheme48 (which uses rationals) mailing
> list, and nobody ever complained. Besides, if "forcing" is simply saying
> either inexact() (and note that inexact-exact operations are performed
> inexactly) or mixing in an inexact literal (assuming that's what 1.0 will
> be), it might be easier. I don't know ABC well enough to say how the
> forcing mechanism worked.

Scheme has no real users -- only CS types. :-)

ABC's forcing was as simple as writing ~x or mixing inexact numbers.
We did have the notion that 1.0 was an exact literal (to me it looks
exact!) so maybe that was an additional problem.

> [Guido]
> > I think this deserves very explicit mention in your PEP.  An example
> > of how I would go about implementing my own Rational class or
> > extension type would help.
> 
> Well, I don't see why there should be a difference from what happens
> currently. The thing is, the model will not support you telling it
> at runtime what the results for operations on types it already knows
> should be: that would make us Scheme, not Python. 

Agreed.  I think what makes me feel uneasy is that your proposal
assumes that there is One True Numeric Type, and all the rest are
second-class numbers.  Python currently makes no such claim: there are
many numeric types built in and you can add your own types that play
along.  The only thing that makes a difference is that there are
literals for the built-in types and not for the extension types; but
apart from that they have all the same privileges, and the coercion
rules work in everybody's favor (except when they don't :-). Placing
more emphasis on One True Numeric Type runs a risk of discriminating
against the others.

> [Guido]
> > Also, the coercions PEP is still in need of an author.  Maybe you want
> > to take this on too?  It will help your numeric proposal if you can
> > write down how you think coercions should work.
> 
> Smooth, real smooth. OK, sold to the highest bidder -- I take it.
> I'll update it and 0000, and start reading MAL's pages.

OK, it's a deal.  But make yourself a co-author with MAL.

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