So I've been yakking with Ian (tizard.stanford.edu) re the new fractions.py, installed in Standard Library per 2.6, saw it demoed at a recent user group meeting (PPUG).
Python's __div__ is similar to Mathematica's computer algebra notion of division in that you're free to divide any type by any type, providing this makes any algebraic sense, using a kind of liberal duck typing. What I mean by that is __div__ by itself doesn't pre-specify anything, so if there's a meaningful way to deploy the division operator between arguments A, B, then go ahead and do it, write you code accordingly. In Java, we could write __div__ in all different ways depending on valid type permutations (not that Java has operator overloading, just stricter typing at write time means you've gotta post "guards at the gate" in your methods). Python, with late binding, duck typing, won't post guards, but you'll still need to write algorithms capable of sorting out the possibilities. Maybe the user throws you a matrix? Has an inverse. OK, so __div__ makes some sense... fractions.py in contrast, implements the narrow Q type, the rational number, defined as p / q where p, q are members of the set integers. One could imagine a Fraction class that eats two complex numbers, or two Decimals. Computer algebra attaches meaning here, as in both sets we're able to define a multiplicative identity such that A / B means A * B**(-1) i.e. A * pow(B, -1) i.e. A * (1/B). So the results of this operation, Fraction(A, B), might be some object holding the Decimal or Complex result. In generic algebra, everything's a duck, although conversion between types is possible (yes, that sounds nonsensical). fractions.Fraction, on the other hand, barfs on anything but integers, isn't trying to be all divisions to all possible types, isn't pretending this is Mathematica or a generic CAS. Note that I'm not criticizing fractions.py in any way, am so far quite happy with it. I'm simply drawing attention to some fine points. Related: When I went to all the trouble to compose two functions, f and g, using __mul__, I'd get comments like: but the "open oh" (another symbol) is the "composition operator" i.e. "you're only using * because ASCII doesn't include the 'open oh'". However, I was making a different point: that in group theory math texts, we're proud to use "regular" multiplication and division operators for such operations as "compositions of functions" because we're thinking __mul__ and __div__ have that generic meaning -- we neither need, nor want, the proliferation of symbols the "open oh" people think we must need. Note that by "open oh" I'm not talking about "big oh", a different notation that I don't think is redundant, agree with Knuth that if your calculus book doesn't include it, you're probably in one of those computer illiterate schools (ETS slave, whatever). Kirby _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig