Fun with numbers - dammit, but I want a cast!

[Terry Reedy]

"Hannu Kankaanpää" <hanzspam at yahoo.com.au> wrote in message
news:840592e1.0308111236.63bd85c0 at posting.google.com...
> By the way, do you know a reason why after doing
>
> from __future__ import division
>
> this still happens:
>
> >>> 3.0 // 2
> 1.0

This follows the general rule that float op int is a float.

> Wouldn't it be more convenient to present the resulting whole
> number as an integer now, since division operation on integers
> works correctly? At least IMO the operation
>
> >>> 3.0 // 2
> 1
>
> would be more convenient and natural, and floor division could then
be
> used to get array indices for example:

A language designer has to think through all the ramifications of each
decision and not locally optimize.  Guido has done fairly well at
this, and probably better than most of us would.  He might someday
decide to go for further number unification -- of integers and
floats -- but there are questions to consider.  What would you have
2.22222e300/2 be?  A loooong long?  Should 2.5*4.0 become an int (so
it can be an array index)?  Should 'normal' users of floats (for math
calculation) be time-penalized by automatically adding an isint? check
to each float operation just so the occasional user who actually want
the conversion can get it without being explicit?
(I think not.)

Terry J. Reedy