[Python-Dev] trunc()

[Guido van Rossum]

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/)