Comment on PEP-0238

[Paul Prescod]

Terry Reedy wrote:
> 
>... However, in a general case such as
> 82/4, the expression is more obviously a problem to be solved (which is how
> the interpreter sees it) rather than an answer in itself and the assumption
> of divisibility may well be disasterously wrong.

I strongly feel that in the modern world, people will see an unadorned
82/4 as 20.5. Go ask someone on the street: "What's 11 divided by 2." If
they are good enough at mathematics to even figure out an answer, they
will usually respond 5.5. Very few would bother to ask you whether you
mean "count division." Very few would answer 5. Try it with your family
and (non-mathematician) friends.

We could each work up more and more complicated expressions of the
question but I don't see that as relevant. The Python interpreter
presents no such "background". The person is given a raw command line
and asked type an expression that evaluates to 5.5. Most people will
type 11/2 (if we disallow directly typing 5.5!). 

The prevalence of calculators moves people more and more in that
direction every day. They choose to truncate (or not) after the
calculator has done the division.

>...
> Underlying these formulations of the survey question is the observation
> that most arithmetic is done to answer questions about the 'real' world by
> using numbers to represent or model quantities of things in the world.
> When so, each number has an at least implicit unit attached.  In this
> context, the fundamental question is whether the unit is divisible (or is
> allowed to be) or not.  If not, one uses (in Python) an integer (or long).
> If the units are divisible, one should tell readers and the interpreter by
> using divisible numbers (floats, complex) to model them, either from the
> start (by adding '.0') or at least at the point of division (by converting
> with float()).  The suffix '.0' says "Yes, this number is currently a whole
> number (whether by design or accident) but it represents something that is
> splittable and which we may well want to split into fractions."  

I do not think it is very good idea to use two syntaxes that are
semantically equivalent in "real math" to indicate divisibility. Perhaps
we should have a "divisible" keyword. And maybe one day we could say
that 5.00 represents not double-precision math but *triple* precsion.
Adding zeros to the end could get you more and more precision. You see
my point? Adding mathematically meaningless numbers to the front and/or
back is a terrible way to change the properties of the object you are
creating.

But anyhow, this is not the crux of the issue.

In a dynamically typed language with no type declarations it makes more
sense to define the nature of the operation *at the point of the
operation* and not at the point where the value is initialized. If you
write a function like this:

def teachersPerClassRoom(teachers, classroom):
    return teachers/classroom

you absolutely do NOT want the users of this function to accidently
subvert it and get meaningless answers by passing it "3.0" instead of
"3". Therefore to make this safe, you need to do this:

def teachersPerClassRoom(teachers, classroom):
    return int(teachers)/int(classroom)

(or something like that)

I do this on *every* division that works with paramaters because that's
the only way I can be explicit and confident. And of course when I want
float division I do the opposite. Eventually after I do this a thousand
times or so I realized that I'm really selecting between two different
logical operators that happen to be sharing the same syntactic body. And
I'm selecting between these two operators in a syntactically obtuse,
runtime-inefficient manner. If I want count division, I want count
division. It doesn't matter if I'm handed a floating point number that
happens to be integral.

> Requiring
> that people think about divisibility in choosing a number representation is
> no more burdensome (and I think less so) than requiring them to think about
> mutability in choosing a tuple versus list sequence representation.

Many Python hot-shots admit to occasionally being bitten by the
int/float problem whereas we never have trouble with tuple/list. You may
be smarter than us, but Python is not only for smart people. The
confusion caused by this is well-documented:

http://old.eleceng.uct.ac.za/courses/EEE103W/python/yhslug.tux.org/obp/thinkCS/thinkCSpy/chap02.htm
http://groups.yahoo.com/group/python-list/message/42970
http://www.amk.ca/python/writing/warts.html
http://www.python.org/doc/essays/cp4e.html

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook