proposed language change to int/int==float (was: PEP0238 lament)

[Bengt Richter]

On 28 Jul 2001 07:55:47 GMT, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:

>Fri, 27 Jul 2001 13:37:51 GMT, Guido van Rossum <guido at python.org> pisze:
>
>> If we have rationals in our numeric tower, I definitely want (5/2 - 3/2)
>> to be usable as a sequence index,
>
>This doesn't work in my model. The simplest way to let it work is to
>treat ints (with longs) and rationals as representation details of
>the same concept (no matter if it's the same Python's type or not).
>
I think hiding representation details is a good goal when they are
irrelevant to the true meaning of the program. Otherwise it's arms-length C ;-)

OTOH, maybe there could be a gradual shift to indications that are
more like optimization hints that are needed for a while, but eventually
get ignored -- like 'register' in a C compiler that knows more about its
target than the coder, at least for big chips.

>This is not nice IMHO and it leads to more cases when the type of the
>result depends on the value of the argument (x**y returns at least
>a float when y is a rational, but may return an integer when y is
   ^^^^^-inexact           vs.            exact--^^^^^^^
>a nonnegative integer) and turns some TypeErrors into ValueErrors
Actually, with rationals, could't you return the inverse rational
for negative y integers ;-)

>(e.g. s[1/2]).
>
It ripples a lot, probably, but if you eliminated 'types' that are
really representation names, maybe the type of the result would be
number or complex, and exact or not. But I imagine that's a big change.

OTOH, there must already be a distinction between indexing with an int
versus a long, so dispatching to something that tries to make an int
(or do you actually internally allow more than a C int?) out of a rational
shouldn't be that bad. The usual case should be fast still.

>I would not make 5/2-3/2 usable as a sequence index. My style is more
>"typeful". But you decide.
>