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

[Ondrej Certik]

Hi,

with Andrew's permission, I am starting a new thread, where our
discussion is ontopic. :)

My original question was, that I would like to override 1+1 to return
MyClass(1, 1) or something.
Robert said it would break other libraries and Andrew said this:

On Mon, Aug 18, 2008 at 9:23 PM, Andrew Dalke <dalke at dalkescientific.com> wrote:
>> There are basically two possible options:
>>
>> 1) global overloading of +
>> 2) allow to tell Python that "1" is not its int, but ours Integer.
>>
>> BTW, Sage just preparses Python for exactly this reason and
>> substitutes all numbers like 1 with Integer(1). This really sucks
>> imho.
>
> How would you like to do it?  Any solution I can think of
> would cause huge problems.  For example, being able to change
> int.__add__ would cause systemic problems throughout the
> code base and would prevent, or very much hinder, migration
> of Python code to C.

Agree.

>
> Changes to support a different constructor for basic types,
> on a per-module basis has its own problems.  When are the
> new types specified?  In the module itself or by the code
> which imports the module?  Can the definitions be changed
> on a scope-by-scope level?
>
> Now, I can imagine a Python with builtin multimethod
> dispatch defined via static scoping, so that
>
> def __add__(left:int, right:int):
>  return __builtin__.__add__(__builtin__.__add__(left, right), 2)
>
> def __int__(s):
>  return Decimal(s)
>
> might work, but even here there's a problem because the "2" in
> __add__ gets replaced by a Decimal, when I really want it to
> be an integer.

Not getting why is "2" replaced by Decimal if you don't want to? If
you don't want it, you can just reimplement
 __int__(s). This would of course be only active in the module where
it was defined.

>
> So I don't see how you can do it in the context of Python.
> In the context of a very different programming language,
> sure, it's possible.
>
>
>> But that's what Sage is doing, they just preparse the input. But in
>> SymPy we'd like to use it as a regular Python library in users
>> programs, so imho preparsing, or custom compiling using your package
>> is not really an option, is it?
>
> Use a different extension, like ".sympy" and an import hook
> which does the .sympy -> .pyc conversion.
>
> But it's not one I recommend for real code, at least not
> without a lot of personal experience to see if it's worthwhile
> in the face of the downsides.

Yes, this is a mess, this is just like preparsing. Well, not like --
this is preparsing.

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]?

Ondrej