[Python-Dev] trunc()

[Raymond Hettinger]

> [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.



> 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.


> After all that, here's my current proposal:
> 
> - Deprecating int(<float>) 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(<float>) being deprecated.



> - 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.

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(<float>).


Raymond