[Python-Dev] trunc()

[Raymond Hettinger]

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


> I don't think that Excel should be held up as a shining example for
> Python.

It is simply a datapoint.  We don't care why they chose int() for
truncation.  The important thing is the subsequent user experiences
which indicates that people do not have a problem with it.
When it comes to int() and round(), people just get it.
I've taught spreadsheets to a lot people and no one has ever
construed int() as meaning round().  What was your experience
with 18 years of python? Was it a recurring a point of confusion?
On the newsgroup, helplist, and tutorial list, I never seen this
come up as problem.

I looked in other places for corroboration.  My HP-12C has
intg and frac buttons.  In BASIC, int() means to return the
integer part of a floating point number.  The surprise find
was that int() in Matlab and Maple means integrate :-)
FWIW, Perl's int() does what ours currently does.

One other thought:  In Python, it has been nice that we have simple type coercions using the type name:
* set(p)-->q    can accept a list, tuple, string, or any iterable and make a set
* int(p)-->q     can accept an int, long, float, or string and make an int
* float(p)-->q  can accept an int, long, float, or string and make an int
* list(p)-->q    can accept a list, tuple, string, or any iterable and make a list
* unicode(p)--> can accept a str, buffer, or unicode object and make a unicode object
It's a bit weird to decide that int() needs to lose that capability so we get generalized Integrals as output.  What's wrong with 
coercion to a concrete type?



Raymond