Ondrej Certik wrote: > Hi Christian, > > On Mon, Aug 18, 2008 at 11:22 PM, Christian Heimes <[EMAIL PROTECTED]> > 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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion