Changing the Division Operator -- PEP 238, rev 1.12

[chris liechti]

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)


and now for the positive things...
I can agree with the motivation section. Now that the big picture mostly 
clear - i like it. (Can't wait for a unified numeric model, it sounds good
;-)

chris


the following two reasons have changed my mind from "oh no! - code breaks" 
to "yes! let's do it":
Guido van Rossum <guido at zope.com> wrote in
news:mailman.996263475.24304.python-list at python.org: 
> PEP: 238
... 
>     It is the opinion of the authors that this is a real design bug in
>     Python, and that it should be fixed sooner rather than later.
>     Assuming Python usage will continue to grow, the cost of leaving
>     this bug in the language will eventually outweigh the cost of
>     fixing old code -- there is an upper bound to the amount of code
>     to be fixed, but the amount of code that might be affected by the
>     bug in the future is unbounded.
> 
>     Another reason for this change is the desire to ultimately unify
>     Python's numeric model.  This is the subject of PEP 228[0] (which
>     is currently incomplete).  A unified numeric model removes most of
>     the user's need to be aware of different numerical types.  This is
>     good for beginners, but also takes away concerns about different
>     numeric behavior for advanced programmers.  (Of course, it won't
>     remove concerns about numerical stability and accuracy.)
...

-- 
chris <cliechti at mails.ch>