Deposing Dictators

[Paul Prescod]

Stephen Horne wrote:
> 
> ...
> 
> The facts are quite simple, though. Some on the pro-PEP have tried to
> use field theory as a justification for the claim that integer
> division does not exist in mathematics, and should therefore be
> supported only through a distinct operator. 

I think it is quite the opposite. Truncating division is *so important*
that it deserves its own operator so that people who see it can know
exactly what they are dealing with, without relying on comments or other
contextual clues.

> ... Yet they are quite happy
> to lose the distinctions between numeric domains by discarding the
> metadata implicit in types, apparently simply to suit the needs of
> heavy users of floats and first-day programmers.

As I've said elsewhere in the thread, experienced programmers also get
bitten by this problem. It is a well-known Python "gotcha" for newbies
and experienced programmers alike.

>...
> Guido then raised the view that other languages would only be relevant
> if we knew the rationale for the change. At which point I noted that
> Java deliberately kept the division behaviour from C and C++ whereas
> Ada deliberately changed from the two-division-operators used in
> Pascal etc. That is, where a language has been created based on a
> deliberate attempt to take past languages and clean them up, the only
> two examples I'm aware of have shown a clear preference to division
> the same way that Python currently does it. And the rationales are
> available on the web if you care to look.

Decisions made in the construction of statically typed languages are
totally irrelevant. In terms of relevancy could just as easily discuss
what various 8-bit CPU designers chose to do. The division problem is an
issue in Python *because it is a dynamically typed language* and because
the "metadata" attached to types is hardly ever explicit in the
language. 

>...
> How many people around here have explicitly admitted they are wrong
> when they are wrong?

http://aspn.activestate.com/ASPN/Mail/Message/687223

Your tendency to bring in the kitchen sink into these arguments makes it
hard to respond and gives one the impression that the conversation will
never crystallize into a core of technical disagreement that could be
debated. It seems that it will always spin out into a new tangent.

The core issue, from my point of view, and, it seems, from Guido's, is
that Python encourages you to think of integers as a performance
optimization for rational numbers. Floats are also a performance
optimization for rationals. If Moore's law keeps up we will probably one
day move from the optimizations to the "real thing." That's where Guido
would like to go.

That doesn't mean that "discrete mathematics" is a degenerate case of
"continuous mathematics" merely that you should indicate that your
domain is discrete mathematics in your *operators* and not in your
*types* becaues Python is a language where the types of things are
"declared" miles away from where they are used. That has nothing to do
with newbies. It has to do with people trained in most modern school
systems to think of integers as a special case of rationals.

On the other hand, given that we have to choose operators for the two
different types of divisions it only makes sense to choose operators
that correspond with people's expectations (both newbies and those with
merely weak memories like me). If you walk out on the street and ask
hundred people for the value of 2/5*5 or 2÷5*5, the number that will
respond "0" is vanishingly small.

So the current behaviour is wrong *semantically* because it frequently
causes people to write code that misbehaves silently in the face of
integers. And using "/" to mean remainder division is wrong
*syntactically* because it is confusing and causes people to write even
more buggy code. So there is a problem and Guido is fixing it.

You could also claim that Python's use of floats as an approximation for
rationals is confusing -- nobody would disagree. One day that will
hopefully be fixed also. But one issue at a time...
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook