[Edu-sig] More spillover re the division PEP

[Kevin Ollivier]

----- Original Message -----
From: "Kirby Urner" <urnerk@qwest.net>
To: <edu-sig@python.org>
Sent: Wednesday, July 25, 2001 10:27 PM
Subject: [Edu-sig] More spillover re the division PEP


> From: Kirby Urner <urner@alumni.princeton.edu>
> Newsgroups: comp.lang.python
> Subject: Nostalgia for the present (re the infamous PEP)
> Date: Wed, 25 Jul 2001 10:10:27 -0700
>
>
> I tell ya, given all the uproar over // vs /, I'm already nostalgic for
the
> good ol' days (these are them), when / left
> it up to its arguments to determine the type of the result.
> In so doing, it followed the same type conventions as the
> other arithmetic operators:

I guess I saw things differently up until now. I always thought Python, by
design, performed the conversion whenever the conversion was needed. This
ensures that when you run an arithmetic operation, you get the result - not
a type error or lost data. I would bet this reasoning accounts for why many
newbies stumble on the division issue. I now realize that is not how Python
works, but why shouldn't it work that way? I don't mean to sound as if I'm
complaining, I would just like to know why it works the way it does.

> My own view is there's a lot of rationale for either way of
> doing it, with the fact of the initial design choice weighing
> heavily on the side of keeping it the way it is.  I prefer that
> newbies learn that type(int/int)==int and that pro programmers
> sometimes "get burned", and that Guido not be apologetic
> or remorseful for this initial design choice -- nor for making
> Python case-sensitive (a perfectly reasonable decision as
> well -- it's gotta be one way or the other, and there's plenty
> to say in favor of either).

May I ask why you prefer this? What is the benefit for the Python programmer
to use this format? I really think the change should be considered,
especially since it is a stumbling block for new learners. (I imagine it is
especially frustrating to hobbyists learning it on their own time, who don't
have a professor to consult.) I think also that demand for this feature to
be changed will increase as more and more people start using Python, so it
may be good to address it now.

I think the simple, deciding factor on the issue is whether or not most
programs (and progammers) need or expect an equation like "1/2" to evaluate
to 0. If 0 is the "correct answer" in a majority of situations, then the
current behavior should stay. However, if 0.5 is the "correct answer" in a
majority of situations and many programmers are thus writing "division
functions" to type-check and convert arguments to ensure this answer is
returned, then the behavior needs to be changed. I personally feel it should
be changed as the PEP at least ensures that (for most purposes) no one has
to write their own division function to ensure they get the answer they
expect. (I actually like Tim Peters' idea of the "use integer" directive.)

As you say, there are good rationales for both approaches, and I don't think
it is a matter of "right or wrong". That is why I feel we shouldn't really
focus on the reasoning for both approaches - they are both quite sound.
Instead, I think we should focus on how Python can be most useful to people.
We should keep the people being "burned" to a bare minimum, and I doubt we
can ensure that all the Python training out there sufficiently addresses the
division issue.

> To take a page from our favorite giant:  It's not a wart (bug),
> it's a feature.

Ah, but beauty is in the eye of the beholder. I doubt many of us would
describe our experiences with the software giant as 'full-featured'. =)

Kevin