[Python-Dev] trunc() (original) (raw)

Guido van Rossum guido at python.org
Sun Jan 27 22:24:55 CET 2008

On Jan 27, 2008 11:54 AM, "Martin v. Löwis" <martin at 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/)

More information about the Python-Dev mailing list