Sorry for jumping in so late. I'd like to argue in opposition to 238. 1) pep 238 introduces significant backwards incompatibility. Existing code may work differently, or may even fail. Consider x/2&1. If x/2 is automatically promoted to a float as in pep 238, you'll get an error: "TypeError: unsupported operand type(s) for &". If you want to write code that will work now and in the future, you'll need to do: int(x/2)&1 which is tedious and error prone. 2) pep 238 breaks consistency with C, C++ and Java. Considering that, like C++ and Java, Python incorporated most of C's operators including all of the integer operators (<<, &, |, ^, etc.), having one operator behave differently will impede transfer of knowledge to/from those languages. This is especially troublesome since python is so often used in a hybrid C or Java environment. 3) pep 238 makes the language inconsistent with itself. None of the other operators return a float for integer arguments. In general terms, there's an automatic promotion from int to long int to float. 4) The rationale given for pep 238 is that 1/2==0 is a "hump in the learning curve" and "manages to trip up new programmers regularly." This may be the case, but it's not clear that pep 238 reduces the learning curve. I think it just moves the hump a little farther down the road and possibly makes it bigger at the same time. Consider trying to teach type promotion. If you now have to include "except for '/'" in every explanation, it will be a much harder concept to grasp and apply. As long as Python treats integers differently than other numbers (e.g. doesn't allow the use of certain operators like '&'), users will need to understand that there is a difference between integers and floats and what the ramifications are. -- Comparisons with Perl have been mentioned. In Perl 1/2==0.5. However, what Perl does is _radically_ different from what is being proposed. Perl operates on "numbers" which in most cases behave like floats. Internally, ints are used where possible for efficiency, but as far as I can tell, there's no way to determine whether an integer or a float (with an integer value) is being stored, and it doesn't matter. Perl just jumps back and forth between integer and float (and even string) automatically, always trying to "do the right thing." Perl _almost_ always does what you want. However, it often feels a little bit too magical, that it's hard to develop an intuition for what's going on under the hood. If Python could be made to work like Perl and work on "numbers" without making users worry about ints vs floats, this would seem to be a much better approach. However, it seems like much too fundamental a change to be making at this stage of the development of the language. Brent