PEP0238 lament

[mcherm at destiny.com]

Guido writes:
> [...]
> Because all Arthur does is tick me off, I'll leave it at this -- 
> maybe someone else can explain it all to him.

Well, I'll see what I can do. In the language there are (at least)
two distinct things we might want to do when "dividing" A and B:

  (1) split A up into B parts
  (2) find how many B's fit in an A

A good example of (1) is float division, and the cannonical example 
of (2) is "int division", aka "div". These are DIFFERENT THINGS.
For instance, if you are implementing a sort algorithm, you may
well want (2) in a place where (1) will never do! On the other
hand, if your program is performing CAD drawings, then (1) is
probably the meaning you need. Note that (2) often makes most sense
with integers (especially since it always gives out an integer),
while (1) may make sense with floats, rationals, fixed-position
decimals, as well as various other numerical types.

So I'm hoping that everyone reading this can agree, BOTH (1) and
(2) are USEFUL things, and a good language should allow BOTH. If
not, then please stop reading: there's no way I can convince you.

Given that you want both (1) and (2), there is just one problem:
the syntax "A / B" is the ideal syntax for BOTH of these purposes.
It's ideal for (1) because the mathematical operation of division 
is traditionally represented with a "/", and it's ideal for (2) 
because C and other languages have historically used "/" between 
integers for (2). In my opinion (and those of quite a few others), 
this is pretty lopsided: (1) is probably used more often, so it 
should get priority, PLUS just imitating C isn't very convincing 
since other languages (eg: Pascal) use other syntax, PLUS the use 
of division in mathematics is far more widespread and well-known
than the use of "/" in C, PLUS the people who intend to use (2)
will probably be able to remember to use a different symbol. So
if you believe these arguments, then the next time you go out
and invent a new language, you'll use "/" to mean (1), not (2).

But Python is not a new language, and in existing versions of
Python, "/" has meant (2) if both arguments were integers. To
change this now is VERY bad, because it will break lots of 
existing code. It probably won't be hard for existing programmers
to adapt, but having to repair all those old scripts is a VERY
BAD THING.

So Guido is trying to balance two things: the desire to use "/"
to mean (1) in all cases, regardless of the type of its arguments,
and the desire to keep Python stable, without breaking lots of
existing code. The issue is important because we often see
newbie bugs based on this issue, and because if the change is
EVER going to happen, it HAS to be soon... the longer he waits,
the more old scripts there are which will have to be broken.

In the end, after hearing all of the arguments (and if you haven't
spoken up yet I STILL suspect someone else has made your argument
for you before in a previous usenet thread), Guido has apparently
decided that the design improvement is worth breaking old scripts. 
Obviously, that means that tools and techniques (warnings, type
inferring source checkers, etc) need to be provided which will 
help in that transition... but it'll still be painful. Guido is
well aware of that, and I'm sure he approaches this with
reluctance. But remember, there's a GOOD side too! After the
trasnsition is over, the language will be (in one small way) even 
better than before.

-- Michael Chermside