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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4