[Fwd: Comment on PEP-0238]
johnroth at ameritech.net
Thu Jul 12 17:21:21 CEST 2001
"Robert J. Harrison" <rjh at 3-cities.com> wrote in message
news:7ef50c46.0107080945.30bfa5b4 at posting.google.com...
> Guido van Rossum <guido at digicool.com> wrote in message
news:<mailman.994529832.2013.python-list at python.org>...
> > > However, I think that some details of the numerics also need to
> > > be clarified before you boldly go. Specifically,
> > >
> > > - What about long division? A float cannot capture all results.
> > > Should it raise a Value/Range error?
> > > Should the programmer be forced to use divmod?
> > > Should it return a rational?
> > > I don't really like the last two choices and the first two choices
> > > obviate much of the usefulness of longs.
> > We'll introduce a new operator or function (e.g. div(x, y)) for
> > integer division, which will work for ints and longs. When / is used
> > and the result can't be expressed as a C double, we can choose between
> > yielding Infinity or raising OverflowError; I think probably the
> > latter although with two float arguments this currently returns Inf on
> > most platforms.
> I think this design might hold as an interim approach, but I don't
> find it satisfactory to have this forced coercion to double make
> division by longs sometimes fail ... it's just not in the spirit of
> dynamic typing ... if coercion is forced, it should be to make things
> "work better", not fail.
> Other thoughts
> - Accelerating the consideration of Rationals.
It's inconsistant to have a rational type, and have integer division return
a float! Either integer division should return a rational, or we should take
PEPs 239 and 240 out and bury them. (In fact, if integer division returns
a rational, then there is no need for PEP 240 - 1/2 is perfectly good as
a rational literal!
If we make integer division return a float now, then we're simply creating
another problem when we implment rationals sometime down the path.
More information about the Python-list