Comment on PEP-0238

[Steve Holden]

"Paul Prescod" <paulp at ActiveState.com> wrote in message
news:mailman.994115046.6243.python-list at python.org...
> 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.
>
[ ... not the crux ...]
>
> 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".

Quite untrue. If you are looking for a statistical result over the whole
country you are much more likely to want a fractional answer. Huge spending
decisions are made on the basis of just such calculations, and only Dan
"potatoe" Quayle wold expect to choose between three and four in that
context. You choose the problem domain to suit your argument, so should
allow other people the right to do the same.

>   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.
>
It would seem better, given that you need to be so picky about the
operational semantics, to actually use a language that enforces static type
checking. Or at least write the functions so they realise a ValueError,
suggesting that anyone who calls them with floating point numbers should
change their approach (or vice versa, of course, when the function requires
floating-point arguments).

Otherwise you allow someone to ask what's the average teachers per classroom
when you have 13.5 classrooms and 27.9 teachers. How much sense does that
make? Or do you bother to verify that the int() result is within some delta
of the parameter passed to your routine? If not then your approach will give
results that are just as sloppy (and counter-intuitive to the "average
person") as those provided by default for division.

It seems to me that Python could go altogether too far in this direction,
and I suspect that the CP4E agenda lies behind all this. If someone isn't
capable of learning that dividing two integers gives a fundamentally
different type of result than dividing two reals, they aren't ready for
advanced programming. Period. Please don't "dumb down" the language so it
can be taught to idiots, or we will end up with a language fit only for
idiots.

Next, someone will propose a requirement that

    "four" * "twelve" == "forty-eight"

to be followed by a huge debate on i18n, with the Americans insisting there
should be no "and" in "three hundred and forty-eight", and Unicode issues
arising quite needlessly. After all, if you approach the average person in
the street and ask them 'What's "four" times "twelve"?' you will usually get
the answer "forty-eight".

Maybe I'm being elitist here, and if so then I am unapologetic about it. If
someone doesn't realise that the same operation can yield different results
when they are applied over different domains, their intuitions are a very
poor guide when making important decisions about the semantics of a
programming language.

I am all in favor of arithmetic being "more sensible", but I fear we
disagree about the meaning of "sensible", and so will have difficulty
agreeing on what should be done. Just because something *can* be done
doesn't mean it *should* be done.

damn,-i'll-be-voting-republican-next-ly y'rs  - steve
--
http://www.holdenweb.com/