PEP0238 lament

[David Bolen]

Michael Abbott <michael.g.abbott at ntlworld.com> writes:

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

It's the breakage concern that's what really does it for me, and I'm
pretty much all system control or GUI in my own uses at this point of
Python.  I think the only place I've cared about floating point
division is when computing percentage complete of some operations for
display to a user.

Personally, my threshold for this discussion is different in the
abstract than in the reality of a pre-existing implementation
decision.  I buy the arguments for the functionality difference, and
maybe even for which makes the most default sense.  If Python had
started with / for float, and // for integer division, I would just
just be using // about everywhere in my code.  But it didn't, and I
haven't, and once we introduce the idea of changing this for existing
code my threshold for which makes the most sense to use for "/" raises
quite a bit, for which the current discussions/arguments no longer
sway me.  In such a case, I'm more in favor of stability of the
existing code base.

And as pointed out elsewhere, my systems and installed base are not
incrementing through each release as they occur because of the cost of
doing so.  I'm still managing a base of 1.5.2, and will likely jump
from that right to a release like 2.1 (or maybe 2.2 depending on my
timing and availability of dependent extensions), so it's all too easy
to end up skipping over the "warning" release right into the "break"
release.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/