Python stands at a crucial crossroad of its existence. One highway features the most popular version of the language, Python 2; the other path represents the next generation, Python 3. The release of 3.0 last winter signals an eventual end-of-the-road for Python 2 somewhere down the line. Python 2.x has taken this language, continuing to grow in popularity every year, as evidenced by watching the trending of the monthly TIOBE Programming Community Index as well as its distinction of being awarded the (programming) Language of the Year award twice in a row.
Python has come a long way, from secondary development tool to prime-time; Python 3.x stands to take it even further. However, one aspect of Python 3 concerning some current users is the fact that, for the most part, Python 3 code is backwards-incompatible with Python 2 interpreters.
As we flow further into the transition process, Python 3.x breakage is something that we need to be increasingly concerned with. One of the best places to start is by future-proofing current Python 2 source... you know, "breakage prevention" coding. This can be accomplished starting in Python 2.6, the first release with 3.x features deliberately backported to Python 2.
A article appearing earlier this year (March 2009) on InformIT gave an overview of the major differences between Python 2 and Python 3, including the critical role that 2.6 and all remaining 2.x releases play in the transition process. This time the focus is on one of the more noticeable core changes that is of particular interest to users, and that is the division operator being altered to only performing "true division."
New Division Functionality
You need to know at least that the math functionality is changing, even if you don't care as much about the actual implementation. Many programmers recognize that this is one of the most controversial updates to Python so far.
What is "true division" you ask? It means that even if with a pair of integer operands, the result is a floating-point value instead of a truncated integer result.
Changing this default behavior is an often emotional issue, usually based on your previous programming experience. Many flame war battles – here is one and here is another – have already been waged, but those who believe in "true division" finally won out. It's too late to participate because these heated discussions occurred nearly a decade ago during the summer of 2001. This change to Python that we are discussing here actually began with the 2.2 release which debuted at the end of that year.
Regardless of your personal take in the matter, I hope that after reading this piece, you won't be coding 1 / 2 relying on its result to be zero (you will get an answer of 0.5 with any Python 3 release). To highlight the before and after, let's (re)define some terminology and their relationships and behavior with integer and floating-point operands.
This is the default division operator behavior in Python 2.x as well as in today's dominant programming languages such as Java and C/C++. When presented with integer operands, classic division truncates the decimal place, returning an integer (also known as floor division). When given a pair of floating-point operands, it returns the actual floating-point quotient (aka true division).
Here is an example illustrating classic division functionality:
>>> 1 / 2 # integer truncation (floor division) 0 >>> 1.0 / 2.0 # returns real quotient (true division) 0.5
True division is where the result is always the real floating-point quotient, regardless of operand type. This is the default division operation in any Python 3.x release. As mentioned earlier, most Python 2 releases have both behaviors built-in; to take advantage of true division in 2.2 and newer 2.x releases, either start the interpreter with the -Qnew option or import division from __future__. Once you do that, the division operator ( / ) only performs true division:
>>> from __future__ import division # 2.2+-only >>> >>> 1 / 2 # returns real quotient 0.5 >>> 1.0 / 2.0 # returns real quotient 0.5
A new division operator ( // ) always truncates the fraction and rounds it to the next smallest whole number toward the left on the number line, regardless of the operands' numeric types. This operator works starting in 2.2 and does not require the __future__ directive above.
>>> 1.0 // 2.0 # floors result, returns float 0.0 >>> -1 // 2 # negatives move left on number line -1