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

Guido van Rossum guido at python.org
Sun Jan 27 06🔞23 CET 2008

On Jan 26, 2008 2:53 PM, Raymond Hettinger <python at rcn.com> wrote: [Jeffrey]

> I've been > advocating trunc() under the assumption that int(float) would be > deprecated and eliminated as soon as practical

And how much code would break for basically zero benefit?

We'll see. Jeffrey did say "deprecated" and "as soon as practical". A -3 warning in 2.6 could do wonders.

This position is totally nuts.

Hold it right there. You may disagree, but that doesn't make it nuts.

There is actually quite an important signal to the reader that is present when you see trunc(x) but absent when you see int(x): with trunc(x), the implication is that x is a (Real) number. With int(x), you can make no such assumption -- x could be a string, or it could be a totally different type that happens to define int, perhaps a custom date/time type (I believe mxDateTime supports this).

There is nothing wrong with int() as it stands now. Nobody has problems with it. The tools is ubiquitous in other languages,

Talk to C++ experts. They have a huge beef with C's confusing use of casts for two different purposes: reinterpretation of the same bit pattern vs. value conversion. Python problem isn't quite the same, but I still really wish I had followed Pascal's lead instead of C's here: Pascal requires you to use trunc() to convert a real to an integer. (BTW Pascal also had the division operator right, unlike C, and we're finally fixing this in Py3k by following Pascal's nearly-40-year-old lead.) If we had done it that way, we wouldn't have had to introduce the index() builtin and the corresponding infrastructure (index and a whole slew of C APIs).

spreadsheets, and calculators.

I don't think that Excel should be held up as a shining example for Python. At least, that would be quite a change.

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

More information about the Python-Dev mailing list