[Python-Dev] functions vs methods (was Re: trunc()) (original) (raw)
Guido van Rossum guido at python.org
Mon Jan 28 23:48:24 CET 2008
- Previous message: [Python-Dev] functions vs methods (was Re: trunc())
- Next message: [Python-Dev] functions vs methods (was Re: trunc())
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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/)
- Previous message: [Python-Dev] functions vs methods (was Re: trunc())
- Next message: [Python-Dev] functions vs methods (was Re: trunc())
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]