PEP 238 (revised)
Guido van Rossum
guido at python.org
Fri Jul 27 19:49:09 CEST 2001
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/)
More information about the Python-list
mailing list