Hi Fredrik Fair enough; I wasn't precise. Upon further reflection, I actually meant floor division, via the // operator. In the following snippet:
>>> 4/2 2 >>> 4//2 2 >>> 4.0/2.0 2.0 >>> 4.0//2 2.0 >>> 4.0//2.0 2.0 We know the last two operations can only return what are effectively integer numbers (or raise an error), but the type that gets returned for a valid operation is a float. Now, I'm not pretending to know much about this stuff, just pointing out that that behaviour is interesting. Just like how MvL pointed out to me in a recent thread that in certain cases .read().splitlines(True) is significantly faster than .readlines() on some file objects: that's interesting. I am sure there are good reasons for this, and I can't imagine that the issue of return type didn't come up when discussions about the floor division operator was discussed; in fact, thinking about it a little more, I suspect this operator is probably more likely to be used in a sequence of floating-point operations anyway, for which the current implementation saves a type conversion that might have been necessary had it been made to return int to start with. So regarding my previous statement: >> I agree that integer division should return an integer, >> because using the operator at all means you expect one. I am not so sure now :) By the way (regarding PIL), have you seen this site: http://www.greyc.unicaen.fr/~dtschump/greycstoration/index.html It is an open-source project implementing fancy methods for cleaning up images and (my interest) resizing images with better clarity on enlargements. I had been working on a python implementation for this kind of thing with heavy leaning on the PIL, but I saw this project on the daily freshmeat newsletter, and so will probably use that code instead. regards Caleb -- http://mail.python.org/mailman/listinfo/python-list