Comment on PEP-0238
Bengt Richter
bokr at accessone.com
Wed Jul 4 21:25:51 CEST 2001
On Fri, 29 Jun 2001 02:10:09 GMT, "Robert J. Harrison"
<rjh at 3-cities.com> wrote:
>From recent discussion it is not clear to me if
>PeP 0238 (http://python.sourceforge.net/peps/pep-0238.html)
>has gained favor, or not.
>
>Two comments. First, its major emphasis is on benefitting
>inexperienced programmers, but, by being inconsistent with
>other mainstream languages, it is not clear to me that it
>is actually a benefit for them. It is certainly not a
>benefit for experiencd programmers that routinely
>switch between Python and other languages. Second, even
>if the change of behavior for divide (/) is accepted, I
>see no point in introducing the // operator. A plethora
>of infrequently used operators will make Python more
>Perl-like. Better an explicit 'cast' to integer.
>
1) I like the current overloading of "/"
2) I think 'type' is a misnomer re float
3) I suspect the subject of coercions and conversions
will churn on a while before a really clean rationale
emerges.
Additional comments:
1) I like being able to write integer expressions concisely. I like it
that +-*/% operating with integers results in integers (and is
presumably implemented with efficient CPU features not using
floating point anywhere).
I do think of integers as a special subset of real numbers, but
I don't want them treated as real when I want to do integer
arithmetic.
If novices need help with the concepts of integer operations,
a 10-minute interactive tutorial should be enough. It would
be a disservice to them to present numbers as if integers were
not special in any way. What the best notation is is a different
issue. Personally, I prefer an overloaded '/' to a special '//',
and I don't mind adding a decimal point to indicate non-integer.
2) To me, floating point is a special representation format for
a special subset of rational numbers. One could argue that it
should be treated as a hidden implementation issue whether and
how floating point hardware is used to represent numbers of
whatever type. I.e., you could have the concept of an optimal
number representation which varied dynamically as values changed
for a 'number' or 'real' type.
PEP 240 (Adding a Rational Literal to Python) might then be
a PEP to choose the appropriate optimal representation for ddd.ddd,
and the type could be number or real, deprecating float.
If you wanted to extend the idea of optimal representation even
further (where optimality preserves exactness?) you could consider
what I'd call deferred-evaluation-literal-expressions (DELEs).
A possible representation would be a tuple identifying an operation
and arguments. The rational type is an example of sorts:
('/',numerator,denominator). ('**',2,('/',1,3)) would let you
represent the cube root of 2 exactly. And so forth.
BTW, if Python numbers get an exact/inexact attribute as in scheme,
I hope Python doesn't arbitrarily force exact=false on all numbers
represented in floating point.
3) In numeric as opposed to strictly integer context, I would think
the goal is to preserve exactness. I think I would be for
PEP 237 (Unifying Long Integers and Integers) on that basis.
Conceivably there might be a coercion from floating point
(rational) to integer-pair rational to preserve exactness, but
there are so many ways to represent numbers that maybe they should
all be hidden from the language definition.
More information about the Python-list
mailing list