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

M.-A. Lemburg mal at egenix.com
Mon Jan 28 12:07:19 CET 2008

On 2008-01-27 08:14, Raymond Hettinger wrote:

. You may disagree, but that doesn't make it nuts. Too many thoughts compressed into one adjective ;-) Deprecating int(float)-->int may not be nuts, but it is disruptive. Having both trunc() and int() in Py2.6 may not be nuts, but it is duplicative and confusing. The original impetus for facilitating a new Real type being able to trunc() into a new Integral type may not be nuts, but the use case seems far fetched (we're never had a feature request for it -- the notion was born entirely out of numeric tower considerations). The idea that programmers are confused by int(3.7)-->3 may not be nuts, but it doesn't match any experience I've had with any programmer, ever. The idea that trunc() is beneficial may not be nuts, but it is certainly questionable. In short, the idea may not be nuts, but I think it is legitimate to suggest that it is unnecessary and that it will do more harm than good.

All this reminds me a lot of discussions we've had when we needed a new way to spell out string.join().

In the end, we ended up adding a method to strings (thanks to Tim Peters, IIRC) instead of adding a builtin join().

Since all of the suggested builtins are only meant to work on floats, why not simply add methods for them to the float object ?!

E.g.

x = 3.141 print x.trunc(), x.floor(), x.ceil()

etc.

This approach also makes it possible to write types or classes that expose the same API without having to resort to new special methods (we have too many of those already).

Please consider that type constructors have a different scope than helper functions. Helper functions should only be made builtins if they are really really useful and often needed. If they don't meet this criteria, they are better off in a separate module. I don't see any of the suggested helper functions meeting this criteria and we already have math.floor() and math.ceil().

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Jan 28 2008)

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611

More information about the Python-Dev mailing list