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

[Paul Boddie]

"Tim Peters" <tim.one at home.com> wrote in message news:<mailman.995943227.11347.python-list at python.org>...
> 
> I'm burned out on the repetition here.  It's not a question of being hard to
> teach.  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.

Indeed. But given that many people know what / is going to do, and
have managed to reassure themselves that y and z are going to be
integers at the relevant parts of their own code, do you think it's
fair to make their code give an "unexpected" result (for them) just
because one could get an "unexpected" result in the general case?

> It's this damage to polymorphism that hurts people in real life, and we've
> had years of testimony about that on c.l.py (even in this incarnation of the
> debate, although it's hard to find unless you read every msg).

I agree with what you say about the dangers of the / operator, and it
is important to at least try to remove the ambiguity (indeed, why not
start raising exceptions), but I don't see why this has to be done by
breaking untold amounts of code that came before just because a group
of people want to reclaim the / operator as their instrument for the
"one true kind of division".

If someone had suggested using // for the int/int->float operation, I
bet that hardly anyone would have complained, apart from some people
who might consider it "language bloat". But instead, it seems that for
the sake of some aesthetic principle the rug is being pulled out from
under everyone whether they want to lie down or not.

Paul