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 <[EMAIL PROTECTED]> 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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion