Comment on PEP-0238

[John Roth]

"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.994532533.10229.python-list at python.org...
> I want to make a pitch for naming it idiv() instead.  The "i" should
> strongly remind that the result is an integer, something "div" says only
to
> former Pascal programmers.  Seems a Positive Good to me if, e.g.,
>
>     idiv(5.0, 3.0)
>
> returned 1 too; i.e., that idiv(i, j) mathematically return floor(i/j).

I like it - my mind had been going in that direction: idiv, fdiv and rdiv to
label the desired output type.

> Alternative:  Given the point about dumbdbm above, the missing half is a
> builtin to return (mathematically) ceiling(i/j) too.  A very direct
approach
> to both is to forget div/idiv and introduce two-argument builtins
>
>     floor(i, j)   # return floor of mathematical quotient
>     ceiling(i, j) # return ceiling of mathematical quotient
>
> instead.  They should also have 1-argument flavors, corresponding to the
> current math.floor and math.ceil.  This would emphasize that the real
point
> to all this stuff is computing floors and ceilings, not really about the
> numeric types of division arguments (that's always been a red herring!).

I think that's missing the point. The current integer division rules aren't
a real
problem to the experianced - it's just one more special case that's the same
as
some languages, and different than others. It's a problem for the novice and
the
occasional programmer.

Going on about floor and ceiling is perhaps mathematically useful (in fact,
no
perhaps about it) but it does nothing for the novice or occasional user.
Replacing
/ completely with idiv, fdiv and (eventually) rdiv would force anyone trying
to divide
to come to grips with what they wanted as a result type. In any case, the
"natural"
result of dividing two integers is a rational, not an approximate real (i.e.
float).

John Roth
>
> but-perhaps-some-herrings-are-too-tasty-to-forego-ly y'rs  - tim
>
>