On Jan 27, 2008 11:54 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
If I'm following this discussion properly, the advantage of trunc() is that a Real-class-that-isn't-float can define a __trunc__ that can return an Integer-class-that-isn't-int, right?
Depends on what you compare to. Compared to int(), the advantage is that trunc() sends a clear message what its semantics is.
In that case, why not have the Real ABC grow trunc(), ceil(), floor(), and round() methods (replacing the __ varieties), and get rid of the builtins/math-module functions?
x.trunc() is just as clear as trunc(x), and doesn't require a builtin.
+1. Students just asked me why len() is not a method, and I didn't know a good answer; the same holds for many other builtins. This is a clear candidate for a method, IMO.
Well, there's the generic functions line of thought, which isn't quite dead yet. And there's the idea that the built-in function can check that the result has a certain type, like len(), which insists on returning an int. But mostly it's because I find things like len(x), round(x) and cos(x) read more natural than method notation. It builds on a long tradition in math and applied math in programming language -- at least round() and cos() do, and so does trunc(). IOW it's a matter of aesthetics, and will never be explainable to everyone's satisfaction. -- --Guido van Rossum (home page: http://www.python.org/~guido/)