Nostalgia for the present (re the infamous PEP)

Kirby Urner urner at alumni.princeton.edu
Wed Jul 25 13:10:27 EDT 2001


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




More information about the Python-list mailing list