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

Guido van Rossum guido at python.org
Sun Jan 27 19:43:23 CET 2008

On Jan 27, 2008 10:29 AM, Raymond Hettinger <python at rcn.com> wrote:

> [Guido] >> 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). > > Can I assume that you agree with this? That would be progress.

I agree that it provides a cue that that input is Real. I don't agree that that has any value. We had a lot of tools that can accept multiple input types. For instance, float() can accept a string or number. We could do like C and split-out the atof() functionality but that just makes two functions where one would suffice.

All I claim is that it has some value for me. If it doesn't have value for you, that doesn't make it worthless.

> Yet another (minor) argument that has always made me uncomfortable > with int() == trunc(): the % operator. I think it's a big improvement > over C that Python's % operator is defined as > > x%y == x - y*floor(x/y) # where / is real division > > rather than C's division, which uses trunc() instead of floor(). In C > this nicely meshes with the definition of int(): you can define x%y as > x - y*(int)(x/y); but not so in Python. I don't want to use this as an > argument for defining int(x) as floor(x), but I do want to point out > that it has always given me a twinge of discomfort.

It hasn't bugged me much, but I do understand.

Progress.

> After all that, here's my current proposal: > > - Deprecating int() is pretty radical, I think it would have to > happen in the distant future. OR not at all. I'm at best +0 on this, > more like exactly 0. I realize that in practice this kills the idea. > The "purist" argument for it would have worked better if it was made > 18 years ago.

"pretty radical" is what I meant when I said "it's nuts" ;-) This is a major piece of progress. Most of the prior proposal was predicated on int() being deprecated.

Good.

> - trunc(), round(), floor() and ceil() should all be built-ins, > corresponding to trunc, round, floor and ceil. Then we > have the four standard ways to go from Reals to Integers, which are > properly extensible for folks who write their own number types. (We > can't control how folks implement round, but we can document > expected behavior -- that's how we treat add and all other > operators too, after all.)

ISTM, you really don't need trunc() in this mix. The ceil() and floor() functions do an excellent job of convering most use cases.

Not really. You'd have to use an if predicated on the sign to emulate trunc() using ceil() and floor(). Or something like sign(x) * floor(abs(x)) -- but we don't have sign().

The overlap of trunc() and int() just isn't worth it. There's the mental cost of having to explain the difference on day one to every beginner. There's the back end cost of every class that has int also needing to decide whether to provide trunc which will typically be the same thing.

In time, I believe it will become self-evident that having both int() and trunc() is a wart. If trunc() goes into 2.6 and 3.0, then we're going to have to live with this for a long time. Purity may suggest that you need trunc(). Practicality says it isn't worth the cost. At least we've made important progress by saving int().

I don't see much cost for end users at all. It's not like trunc() represents a difficult concept. Having trunc() in addition to ceil(), floor() and round() creates a nicely complete set of float->int conversions. Then int() can be defined by deferring to trunc() -- as opposed to round().

My proposal stands (less any talk of deprecation of int()).

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

More information about the Python-Dev mailing list