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