PEP 238 (revised)

Chris Barker chrishbarker at home.net
Mon Jul 30 13:44:54 EDT 2001


Bengt Richter wrote:

> >What I don't get, is why // couldn't return an integer always? It will
> >always have an integral value. I suppose one problem is that the range
> >of integers that a float (C double) can handle is larger than a 32 bit
> >integer can hold. This could be solved in the future with int/long
> >inification, what will be the behaviour then?
> >
> I think it has to do with being consistent with the idea of using the
> representation type as an indicator of exactness.
> 
> Using that idea, float is a visible name and means inexact,
> and int and long are visible and mean exact.
> 
> Floor can't turn inexact to exact, so it must return inexact (i.e., float)
> if it gets an inexact (i.e., float) input.
> 
> int(x) will effectively be an exactness coercion because of the
> representation-type linkage.

I'll buy that. In fact, I like that a lot. The problem, for me, is that
1.0 can't be used as a sequence index. While it may not be know whether
x//y is an exact value, it IS know that it is an integer value, and
should therefor be usable as an index. This brings up the usefulness of
the concept of the inexact integer.

I'm also not so sure about your above rational: While I do understand
that the result of x//y may not be an exact number, given that x and/or
y may not be exact, the question is: does that matter? Acn anyone think
of a case where they would use // (or floor, or ceil, or round) when it
would hurt for the final result to be considered exact?

-Chris



-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------



More information about the Python-list mailing list