[Numpy-discussion] global overloading of 1+1 -> MyClass(1, 1)

Christian Heimes lists@cheimes...
Mon Aug 18 16:22:11 CDT 2008

Ondrej Certik wrote:
  > Ok, in the current state, you don't know either what's going to
> happen. If you write
> In [1]: x/2*3/4
> you have no idea what the result is going to be, you need to analyze
> x.__div__() and start from there. But if you write
> In [2]: 1/2*3/4
> currently you know it will be 0. But imho you could as well analyze
> the global __mul__ (or global __int__, depending on how this would be
> technically implemented) to see what's going to happen.
> I mean what is the difference between [1] and [2]?

Andrew has already pointed it out very well. I like to comment on your 
proposal from the perspective of a Python core developer as well as the 
perspective of somebody who has worked with Guido for more than a year.

I'd bet my life that Guido is never every going to allow it. The core 
types are fundemental to the Python interpreter. Even the possibility of 
pluggable type methods would make the implementation slower, more 
fragile and much more complicated. We'd have to remove several speed 
tricks and special cases for e.g. ints and replace them with slower 

But don't give up hope yet! During the alpha phase of Python 3.0 and the 
revamping of the decimal module, some core developers had an even better 
idea. We were discussing the possibility of making decimals the default 
for float literals. The idea was rejected eventually but it gave birth 
to yet another idea. What about making the *result* of a literal 
pluggable? The Python creates a float for the literal 1.0. Some header 
in a module could replace the default target 'float' with e.g. 

Example syntax (rough idea):

 >>> type(1.0)
<type 'float'>
 >>> with float as from decimal import Decimal
 >>> type(1.0)
<class 'decimal.Decimal'>

Wouldn't that solve your general problem more elegant without breaking 
other modules?


More information about the Numpy-discussion mailing list