PEP0238 lament

[Steve Horne]

On Mon, 23 Jul 2001 16:07:45 GMT, "Tim Hochberg"
<tim.hochberg at ieee.org> wrote:

>Let me stray from the topic for a paragraph here: I'm astounded to discover
>the number of people pining for integer division that truncates towards
>zero. That sort of integer division is horriible. When programming in C,  I
>always had to simulate Python's behaviour in order to get code that might
>take both positive and negative integral values to work correctly. Python
>gets this exactly right.

Probably a good point. I have tended to expect division to round
towards zero - I tend to expect (-a / b) == -(a/b) - but I do
appreciate the extra conditionals and general hacks you can end up
needing as a result. I suppose it depends on what you are doing with
integers - and given that most my integers - being subscripts and
indices - are rarely negative anyway, it's not a big deal anyway.

On this one, my current feeling - a rather vague and dubious
preference I admit - is towards rounding towards zero. Python rounds
towards -inf. Yet I am *not* in favour of changing Pythons behaviour
at all. Division resulting in negatives will be much rarely than
general division - much fewer than half of all cases - because of the
subscripts/indices bias - yet this would still cause much too many
problems to consider it whatever my personal opinion.

>thing. I couldn't disagree more. C-style division in a dynamically typed
>language is an accident waiting to happen. And does this mean that code

There are many ways to deal with that, without pretending that
floating point division is somehow fundamentally different to integer
division when in fact it is simply a logical extension of the same
operation.

>Anyway, not being an educator, I'm not particularly concerned with whether
>integer division is easy or hard to learn. I like the proposal because there
>just isn't a good way currently to spell
>divide-these-two -numbers-using-normal-division. The fact that oponents of

So add a new operator for the new functionality - but don't change the
semantics of the existing one people have been using for years.

>It has been suggested as recently as this morning, I believe, that this be
>rewritten:
>
>def simple_func(x, y):
>   return y / float(x)**2
>
>This is simple, clear and ... wrong, as Konrad Hinsen pointed out several
>days ago. At least it's wrong if complex numbers are ever a possibility. One

Obviously - if complex numbers are considered valid inputs then that
function is wrong. What you are saying, though, is that integer inputs
are invalid and should be coerced to floats. That *CAN* be tested for
and done now without ANY changes to the language. If it's too awkward,
then what is needed is a simpler way to do achieve that. I have
suggested several ways to achieve this kind of result, and one that
achieves EXACTLY that. NONE of those suggestions would break old code.
NOBODY has replied in any way to any of them though.

how about...

def simple_func(x, y):
  $coerce x, y : $integer -> $float
  return y / x**2

Notice I even used my simple prefix-to-indicate-keywords idea to avoid
breaking any 'coerce' identifiers anyone might be using. I admit the
syntax hasn't been thought through - I'll bet there's a dozen holes
picked in it before tomorrow morning - but the principle is simple,
clear, effective and non-destructive.

I think thats number five for my plausible alternatives.

-- 
Steve Horne
Home : steve at lurking.demon.co.uk
Work : sh at ttsoftware.co.uk