[Numpy-discussion] global overloading of 1+1 -> MyClass(1, 1)
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 : 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 : 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  and ?
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):
>>> with float as from decimal import Decimal
Wouldn't that solve your general problem more elegant without breaking
More information about the Numpy-discussion