proposed language change to int/int==float (was: PEP0238 lament)
Marcin 'Qrczak' Kowalczyk
qrczak at knm.org.pl
Thu Jul 26 03:34:46 EDT 2001
26 Jul 2001 17:04:00 +1200, Paul Foley <see at below> pisze:
> I know that; that doesn't mean there shouldn't be a real _type_.
> It doesn't have to be instantiable. If you want to use it as a
> constructor, it can return some appropriate concrete subclass.
In other words it's not a type: it's a function which returns its
argument unchanged or throws an exception. I don't think it's a
useful function.
>> I don't understand you. What practical difference do these diagrams
>> yield? What is wrong in *consequences* of Guido's and mine model
>> which your model puts differently?
>
> The most obvious problem is that it implies that every rational
> can be represented as a float
It doesn't.
It only implies that if you have a choice of converting a float to a
rational or a rational to a float (to bring them to a common type),
you convert the rational to a float.
> [I think it also implies that floats with integral values (1.0, etc.)
> should turn into integers.]
It doesn't. My model makes the result depending on the type of
arguments, not values (except that it matters whether the exponent
of ** is a negative int or a nonnegative int).
It could be changed to unify ints and rationals, i.e. always turn
whole-number rationals into ints. I would not do it for float because
it loses the information that the data is inexact.
>> What happens if you int to float in your model? Rational to float?
>
> What do you mean, what happens? You get a float.
So it works exactly as my model! And you say my model is broken and
yours doesn't?
How it follows from your model BTW? Rationals and floats are unordered
on your diagram.
The clue: what is a practical difference between them? What expression
has different values (including the possibility of different types)
in our models? I can't find any.
--
__("< Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
More information about the Python-list
mailing list