Changing the Division Operator -- PEP 238, rev 1.12

[Paul Svensson]

Guido van Rossum <guido at zope.com> wrote:

>API Changes
>    - Overloaded operator methods:
>
>      __div__(), __floordiv__(), __truediv__();
>
>      __idiv__(), __ifloordiv__(), __itruediv__().

>    In Python 3.0, the classic division semantics will be removed; the
>    classic division APIs will become synonymous with true division.

I think you mentioned that __truediv__ and __itruediv__ will go away
at when we reach 3.0; I think that would be good to include in the PEP.

I also still think that __truediv__ and __itruediv__ cause more
problem than they solve; I've thought about the issue some more,
and I hope I can now explain a little better why.

Consider an existing
	class Foo:
	    def __div__(self, other):
		...

With your proposal, this will break as soon as it's called from
a module importing the future division.

The author of the original class foo then has the option of:

a)	simply adding __truediv__ = __div__

b)	changing __div__ to __truediv__, requiring all users
	of the class to import the future division;
	knowing that it will break again when we hit 3.0.

c)	implementing __truediv__ with different semantics
	than __div__, so that division of foo can behave
	differently depending on wether the user imports
	the future division or not.

d)	and of course, telling me it will work again in 3.0,
	so he doesn't want to spend any effort on changing it
	(or not telling me anything, as that may be).

I'm just totally unconvinced that the advantages of (c)
outweighs both the immediate breakage, and the possibilities
for options (b) and (d).

That's why I would like to ask:
**************************************************************
**                                                          **
** Who out there has a need for (c), please make your case! **
**                                                          **
**************************************************************

If there's really a demonstrated need for this, I would suggest
letting x/y, with future division imported, fall back to __div__
if there's no __truediv__ (and perhaps the other way around after
we switch to 3.0, but I doubt that would be needed).

If there's no demonstrated need, I repeat my suggestion to simply keep
__div__/__idiv__ for x/y and use __floordiv__/__ifloordiv__ for x//y.

	/Paul