On Jan 27, 2008 11:54 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
