>. 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
