proposed language change to int/int==float (was: PEP0238 lament)

[Chris Gonnerman]

----- Original Message -----
From: "Tim Peters" <tim.one at home.com>


> It's largely that it's never sensible for
>
>     x = y / z
>
> buried in the middle of some routine to do truncating division if y and z
> happen to be ints but best-possible division if they happen not to be
ints.

I can grant that.

<hack hack hack>

> I don't detect any trace of that hypothesized motive in Guido.  He wants
to
> repair what he has come to believe is a serious design error, and is
> wrestling with ways to get that done.  What a remarkably different world
it
> would be if people tried to help <wink>.

Some of us have tried.  Besides my alternative, I have seen two others which
allow case-by-case preservation of the old semantics where they may have
been
intended.

I have seen very few comments on them though (except from Stephen Horne).

ASSERTIONS:
    1.  Best-effort handling of division is desirable.
    2.  An explicit operator for truncating division is desirable
        (as in, explicit is better than implicit).
    3.  Code breakage is bad, and difficult-to-detect code breakage
        is worse.
    4.  Difficulty in writing backwards-compatible code is bad (thus,
        code to implement partitioning of a dataset would naturally use
        the // operator in 2.2+ but would not be able to in pre-2.2,
        so the div() function would have to be religiously used, hurting
        readability).

Assertion 1 and 2 conflict with 3 and 4; #4 in particular bothers me.  Many
have said that #3 is irrelevant as we have from 2.2 to 2.4 to fix it, but
I have upgraded several systems directly from 1.5.2 to 2.1 without
substantial
problems; going direct to 2.4 from 2.1 would not be so painless.

SOME way is needed to specify, in module scope, which set of mathematics
rules
should be enforced.  Whatever method is used should (IMHO) be uniform from
2.2
to 2.4; my method, as given, is the only one where the code reads the same
from
2.2 on:

    from __numerics__ import original  # or standard, etc...

Just thinking about the implementation gives me headaches, but Guido and Co.
have readily implemented fancy things like the software-time-machine

    from __future__ import phasers, warp_drive # or whatever

and so my proposal (or a mutation thereof) should be no biggie.

As I said, you can't honestly say we ALL haven't been trying.  It's not that
I
object directly to the change, it's the overall plan/effect/semantics etc.
that
I don't like.

Stephen seems not to want to have to admit to his boss that Python has
changed
the basic rules for division of integers.  I can grasp this... a proposal
like
mine, which allows for other numeric types to be dynamically added to the
language, would be an easier sell:

    Boss:  I heard Python was changing the rules for division of integers.
        Are you sure we should be using such a stupid language?
    SH:  No, boss, you've got it all wrong.  We have a new method for adding
        numeric types, like rationals, fixedpoint, decimals, etcetera, and
        is just happens that the default division mode changed as a
        consequence.  I can easily add a single line of code to any old
module
        and Python will run it under the old rule.  No fault, no foul.
    Boss:  Oh.  Well, carry on.