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

[Guido van Rossum]

"Chris Gonnerman" <chris.gonnerman at newcenturycomputers.net> writes:

> 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).

It's not easy to find the light among the heat.

> 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.

Hm, #4 is relatively new in this discussion (for me, anyway).  I will
have to adapt to this new requirement, which I find reasonable
(although I wish it didn't exist -- but I understand the motivation).

> 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.

You will have at least from 2.2 to 2.6 though (at least two years),
and in reality more because I propose to add a command line option to
revert to old division semantics for several releases after 2.6.

> 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...

Not bad.  But I am still uncomfortable with making the old semantics a
*permanent* wart of the language.  I'd much rather deal with a future
statement for 5 years than with a __past__ statement forever.

An alternative that would not need this would be to require

   from __future__ import division

in order to use the new semantics, and use the proposed command line
option (say, "python -D old") to default to the old behavior as long
as you have to support unconverted code.

> 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.

Indeed, this wouldn't be hard -- although maybe a friendlier syntax,
like "directive blah, blah, blah" might make sense *if* we decide to
do this.  (Which I still don't think is the best solution, but I do
see your point.)

> 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.

Would it be more palatable to you if the new semantics didn't become
the default (or the law) until Python 3.0 was introduced?

That's how Perl dealt with a much larger incompatible language change:
Perl4 was left alone (I believe there are still plenty installations
that require it) and Perl5 was the future.

--Guido van Rossum (home page: http://www.python.org/~guido/)