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