[Fwd: Comment on PEP-0238]
Robert J. Harrison
rjh at 3-cities.com
Sun Jul 8 13:45:43 EDT 2001
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.
- Accelerating the consideration of Rationals.
It seems natural to have long division return a rational, and
int division return a float. This way you always know what you
are getting and it will always work. However, ints and longs
are not on an equal footing which is also desirable.
If rationals cannot be considered on the same timescale,
that PEP should be ammended to make it consistent.
At some point in the future the behviour for longs could be
modified ... the ramifications are less wide spread than for int.
- To get ints and longs on an equal footing we could have some
parameter (import or whatever) that defines the type returned
by /. This way you can choose at runtime if you want a float
or something else. This can also be done with the next ...
- Will standard __closed_integer_div__ method names be defined
so that people can define their own integer types?
More information about the Python-list