[Numpy-discussion] global overloading of 1+1 -> MyClass(1, 1)
Mon Aug 18 16:37:41 CDT 2008
On Mon, Aug 18, 2008 at 11:22 PM, Christian Heimes <email@example.com> wrote:
> 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):
> >>> 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?
It absolutely would. Thanks very much for the email. How is your
proposal (redefine literals) different to just saying to Python --
hey, just call my class when someone writes "1", e.g. proposition 2)
from my first email? Or am I missing something.
I agree with the technical reasonings, why some particular solution is
not good. I.e. I didn't do any proposal, I am just trying to find a
way, so that we don't have to always type
In : Integer(1)/2 * x
In : x/2
some other times. If you know what I mean. Both do the same thing, but
 is very annoying to write and a source of common mistakes that
people do with SymPy, it simply returns 0.
More information about the Numpy-discussion