Language change and code breaks

[phil hunt]

On Fri, 13 Jul 2001 19:26:58 GMT, Guido van Rossum <guido at python.org> wrote:
>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.

Indeed we can easily learn that. However, we cannot easily go back 
and fix all the old Python code that would become broken. I've
just done a quick check and there's 7200 lines of Python code
on my HD I've written. Of those, I use / 3 times. Twice require
integer division, and the other is clearly marked float(x)/y.

Assuming that's a good sample, one line in every 3600 of Python
code will have to be changed. So any change would likely cause
around 30 bugs in a 100,000 line Python program.

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

Indeed.

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

Have you thought of forking the Python codebase for this and
any other more radical changes you propose? I for one would
like to see what sort of CP4E design you can come up with --
including case-insensitive identifiers, etc -- but such changes
couldn't be added to Python itself.

>> Anyway, that's not my problem. :-)
>
>Yes it is!  Unless we find a solution that *works* you will be
>affected.

Consider forking the codebase. Keep the .pyc format, so the new
language will be link-compatible with the old one.


-- 
## Philip Hunt ## philh at comuno.freeserve.co.uk ##