[Fwd: Comment on PEP-0238]

[John Roth]

"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.

John Roth