[Edu-sig] More spillover re the division PEP

Kirby Urner urnerk@qwest.net
Wed, 25 Jul 2001 19:27:12 -0700


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:

   Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)]
   on win32
   Type "copyright", "credits" or "license" for more information.
   IDLE 0.8 -- press F1 for help
   >>> type(1+1)
   <type 'int'>
   >>> type(1+2.)
   <type 'float'>
   >>> type(1*2)
   <type 'int'>
   >>> type(1*2.)
   <type 'float'>
   >>> type(1/2)
   <type 'int'>
   >>> type(1/2.)
   <type 'float'>

But now we're gonna have:

   >>> type(1/2)
   <type 'float'>

The programmer doesn't have to do any casting, as type conversion
when returning a result is automatic.

     def velocity(miles,hour):
         return float(miles)/hour

In the new regime, / is guarenteed to return a float, and // is
guarenteed to return and int, no matter what the numeric args.
This puts / in a new category among the arithmetic operators:
the operator itself ensures type of result, not the args.

But that's because / *is* special in some ways:  + - and * are
all closed in Z (integers), but the integers form a ring, not a
group, with respect to + and *, such that the multiplicative
inverse of j  -- i.e. 1/j or j**(-1) -- is not in Z unless j=1.
This is what's driving / to be coercive, and to differentiate
from //.

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).

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

Kirby