Changing the Division Operator -- PEP 238, rev 1.12

[Guido van Rossum]

cliechti at mails.ch (chris liechti) writes:

> there is just one unpleasan't thing left over:
> in the transition phase its __div__, __truediv__, __floordiv__ and their 
> respective 'i' version for arg assignment. this solution allows the object 
> to "see" what the caller wants for a division type. ok, but..
> 
> classes would need a change when upgrading from 2.x to 3.x ( __truediv__ 
> will become the same as __div__ in 3.x but its not with "from __future_ 
> import division" in 2.x)? what would 3.x do? search for __truediv__ and 
> then for __div__? that would give wrong results with old modules that only 
> have a __div__ (emulating the missbehaviour) and no __truediv__. (ok i 
> don't realy belive in classes emulating some missbehaviour, see next 
> paragraph)
> 
> wouldn't it be better when only __div__ and __floordiv__ were needed? 
> classes could not provide the two diffrent meanings of '/' but how many 
> classes do realy need this? when somebody is implementing his own number 
> object he will anyway provide a true division, wouldn't he?
> this would also *not* introduce a new name that's later unused/merged with 
> __div__. (remember: one obvious way to do it)

I have to think some more about this.  Maybe nb_true_divide should
look for __truediv__ first and then fall back to __div__.  Not so for
nb_floor_divide though: it is a new operator.

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