Andrew Koenig wrote: > Christoph Zwerschke wrote: > >> Anyway this would be an argument only against the variant of typecasting a >> float with a fractional part. But what about the other variant which >> raises an error if there is a fractional part, but works if the float is >> actually an exact integer, like the result of 4.0//2. > > I think that's a really bad idea, because of the possibility that the result > might happen to be an exact integer on one implementation but not another. > In such situations, the fact that it might fail on implementation X may well > be impossible to detect by any amount of testing on implementation Y. Such > untestable errors are such a nuisance that it would better for the language > to encourage programmers to give them a wide berth.
1./20*40 == 2 or math.sqrt(4.0) == 2 may not always be True (on my platform it is True), but on every platform 4.0//2 == 2 should be True. More general, the result of a//b should always be an exact integer, and a//b == int(a/b) for all positive numbers a,b, no matter on which platform. If not, I would consider a//b broken on that platform. And if a//b == int(a/b) is True, I think it is also reasonable to expect that a//b * list is the same as int(a/b) * list -- Christoph -- http://mail.python.org/mailman/listinfo/python-list