Comment on PEP-0238

[Bengt Richter]

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.