PEP 238 (revised)

[Guido van Rossum]

Paul Foley <see at below> writes:

> >       __div__(), __floordiv__(), __truediv__();
> 
> Will __truediv__ become __div__ again in Python 3.0, or what?

Yes.

> I wonder whether there's any need to distinguish (classic) __div__ and
> __truediv__ for user-defined objects, though; I'd think they should
> continue to do what they do now, so you can just leave it __div__.

I don't want to make user-defined classes second-class citizens.
Certainly not with the type/class unification going on.

> >     Floor division will be implemented in all the Python numeric
> >     types, and will have the semantics of
> 
> >         a // b == floor(a/b)
> 
> >     except that the type of a//b will be the type a and b will be
> >     coerced into.
> 
> I'm not sure how to parse that.  a and b are going to be coerced to
> the type of a//b?  But what is the type of a//b?  That's determined
> _by_ a and b, right?  Or is it saying the type of a//b will be the
> type of a, and b will be coerced to that same type?  That's not right.

Sorry, the language was a bit off.  How about this:

    Floor division will be implemented in all the Python numeric
    types, and will have the semantics of

        a // b == floor(a/b)

    except that the result type will be the common type into which a
    and b are coerced before the operation.

Also, I'm adding explicit examples for the built-in types (which
includes the useful information that this is an error for complex).

> >     True division for ints and longs will convert the arguments to
> >     float and then apply a float division.  That is, even 2/1 will
> >     return a float (2.0), not an int.
> 
> What???  Blech!  [remainder of thoughtstream censored]
> 
> Actually, I suppose that makes sense if you think float is above
> rational in the type hierarchy.  To Marcin Kowalczyk: here's an
> example of something that has different results!

I should add a qualifier: as long as we have no rational type.  With a
rational type, 1/2 should return a rational under true division.  But
it certainly should not be 0, because that is classic division, which
is going to be phased out.

> >     - It has been proposed to call // the quotient operator.  I like
> >       this.  I might rewrite the PEP to use this if enough people like
> >       it.  (But isn't the assumption that this truncates towards
> >       zero?)
> 
> Everybody here seems to think "quotient" means an integer?!  I don't
> think so.  I've heard the floor-division result called a "partial
> quotient", but I don't know if that's standard terminology.
> [Mathematicians?]
> 
> [Actually, I guess it is -- since I haven't sent this yet, I looked it
> up in mathematics dictionary, which also calls it a partial quotient]

I'm sticking with true division and floor division for now.  They are
newly introduced terms that are clearly defined at the start of the
PEP.

> >     A. Use x*1.0/y for true division, divmod(x, y)[0] for int
> >        division.  Especially the latter is best hidden inside a
> >        function.  You may also write floor(x)/y for true division if

Note that floor here was a typo; I meant float().

> A two arg version of floor would be a good addition; it can produce a
> more accurate result than doing a division (in the absence of an
> actual ratio type; and more efficiently if you do what ratios)

I don't understand why everybody suddenly associates floor with
division.  It has nothing to do with division -- it is just a
mathematical operator that is useful in the exact mathematical
definition of integer division.

--Guido van Rossum (home page: http://www.python.org/~guido/)