[Python-Dev] trunc()

[Guido van Rossum]

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/)