PEP0238 lament

[Michael Abbott]

Skip Montanaro <skip at pobox.com> wrote in
news:mailman.995900686.5170.python-list at python.org: 

> I suspect that most people resistant to this change share the following
> two traits:
> 
>     * a large body of code to maintain
>     * most arithmetic they do in Python is non-scientific - implied by
>     few imports of the math module in their code
>
> ...  
> I suspect that most people who are
> advocates of the change proposed in PEP 238 either are numerical folks
> or don't have much code that will break.  Numerical folks probably
> import math about as frequently as sys and sprinkle their code
> liberally with calls to float(). 

I think this is quite a helpful observation.  From the professional 
programming perspective, I imagine that there are two types of programming 
task that are relevant to this discussion:

1.  Scientific programs, where presumably the bulk of the work can be done 
using floating point numbers.
2.  System control (I use this phrase *very* broadly) programs where 
floating point *never* makes an appearance (except, perhaps, for friendly 
display to the user).

(Of course, someone might pipe up, what about all that graphical 
programming?)  Perhaps I should add a third category of task:

3.  Graphical programming can, perhaps, be characterised as a mixture of 
scientific calulations and discrete control.  (Please don't take this too 
seriously!)


Anyway, my point is this: integers are used for discrete computation and 
control, and when I perform arithmetic on integers I expect to continue 
working on integers.  The idea that a floating point number might magically 
appear in the middle of my calculations (because I was foolish enough to 
write a/b) does not make me happy.
    Of course, the argument seems to be that I should be happy to use // 
throughout my code.  Perhaps.  Perhaps not.  But what about all that broken 
code, eh?