[Python-Dev] functions vs methods (was Re: trunc())

Guido van Rossum guido at python.org
Mon Jan 28 23:48:24 CET 2008


On Jan 28, 2008 2:28 PM, Daniel Stutzbach
<daniel at stutzbachenterprises.com> wrote:
> On Jan 28, 2008 4:00 PM, Guido van Rossum <guido at python.org> wrote:
> > No, using trunc(x) makes it clear that the argument and return value
> > are numbers. Using x.trunc() doesn't.
>
> How often do you expect someone to be looking at code where a trunc()
> method is being called and the variable could plausibly be both a
> number or something else?  (a Google Code search for "def trunc(self)"
> lang:python returns 1 hit)
>
> How does the that additional value weigh against the cost of adding
> another builtin and trying to explain trunc() versus int() to new
> users?

It's all pretty hypothetical at this point. I do think that the
*concept* of trunc() is very easy to understand so the cost to the
user of having to learn it (only when they encounter code that uses it
or feel the need to use it themselves) is negligible.

One thing I'm beginning to feel more and more strongly about is that
round, trunc, ceil and floor all belong in the same category, and
either should all be builtins or should all be in math.

I should also admit that the 2-arg version of round() was borrowed
from ABC, but the use case for it there doesn't map to Python: in ABC
it's the only tool you have for floating point formatting on output,
while in Python the same thing would typically be done with "%.2f" % x
rather than round(x, 2).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list