Language change and code breaks

[Peter Hansen]

pfenn at mmm.com wrote:
> 
> Is there really much code that depends on 1/3 == 0 being true?

Unfortunately, while code a chemist writes is very likely never
going to rely on the current integer division behaviour, code
written by those of us in computers who tend to work closely 
with the hardware (where we are constantly thinking in terms
of bytes, words, signed and unsigned, memory locations, bits
and nybbles, etc.) will fairly often write code which depends 
on the current behaviour.  (By the way, no, we would never
write 1/3 and expect 0, but 99% of the time we are not talking
about constant expressions such as this... but you knew that.)

I can't see a simple answer to this.  It looks as though there
are two camps, to both of whom it is absolutely essential that 
Python act in a specific way.  And the two ways are completely
incompatible.

Doesn't that mean that the only solution that can be accepted
without causing serious complications is to make the change,
but clearly support a command line option (or some other
configuration setting) to enable the current behaviour,
so those who have depended on integer division can continue
to run old code under the new engine without fear of
breakage?

(I know, it's not perfect, but with a little more design
thought it can probably come pretty close.  For example,
code that might have to run on someone else's system, which
might not have the correct setting for integer division,
can use a sys.setIntegerDivision(1) call to force the
desired behaviour.  Or does this have to be on a module-
by-module basis?  Anyway, that's not my problem. :-)

So, O' BDFL, why not take the most Pythonic approach
and use a solution which *pragmatically* achieves a good
practical balance but which causes purists always to feel
a little uneasy and which can lead to perpetual discussion
about "warts" and why other languages are better and.... ;)

-- 
----------------------
Peter Hansen, P.Eng.
peter at engcorp.com