Language change and code breaks

[Guido van Rossum]

Peter Hansen <peter at engcorp.com> writes:

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

Ah, but you professional programmers can easily be trained.  Just the
fact that you can already juggle all those concepts in your head means
that you won't have much trouble learning the additional fact that i/j
returns a float and that integer division must be spelled as i div j.

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

No, that's not it.

The problem is that you have written much more Python code than the
chemists of the world, and if I were to change the language, you would
have to go through all that code to find out which slashes to replace
with 'div'.

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

This has been said many times in other contexts: command line options
to change a particular behavior are evil.  It would mean that library
modules could't depend on either behavior.

If we're going to give users a choice, it's going to be some kind of
per-module switch.

> (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?

Yes, this has to be on a per-module basis.

> Anyway, that's not my problem. :-)

Yes it is!  Unless we find a solution that *works* you will be
affected.

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

Believe me, I'm trying.

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