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

[Dag Sverre Seljebotn]

Ondrej Certik wrote:
> Hi Christian,
>
> On Mon, Aug 18, 2008 at 11:22 PM, Christian Heimes <lists at cheimes.de>
> wrote:
>> 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
>> implementations.
>>
>> 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.
>> decimal.Decimal.
>>
>> 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 [3]: Integer(1)/2 * x
>
> sometimes, but
>
> In [4]: x/2
>
> some other times. If you know what I mean. Both do the same thing, but
> [1] is very annoying to write and a source of common mistakes that
> people do with SymPy, it simply returns 0.

It should be mentioned here that this is exactly what the SAGE preparser
does -- all "2" turns into "Integer(2)", and that idea definitely seems to
work for them. (And so if you want Python behaviour in SAGE, you simply do
"Integer = int", while normally "1/2" becomes a rational object in QQ
because one object in ZZ is divided by another one).

Pluggable literals seems like a much better idea to me, not from pragmatic
but from design reasons -- I would prefer them even in the (very unlikely)
case that they were slower and harder to implement than overriding the
operators for the builtin types.

(But I'm just a bystander here.)

Dag Sverre