proposed language change to int/int==float (was: PEP0238 lament)
Marcin 'Qrczak' Kowalczyk
qrczak at knm.org.pl
Thu Jul 26 09:34:46 CEST 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
>> 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 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
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
More information about the Python-list