Python 3.x vs Python2.x

 

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.

 

 

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)

 

 

 

 

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:

   

 

 

 

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.

 

 

Those arguing for this change feel that Python’s division operator was flawed from the beginning, especially since Python is a common choice as a first programming language. New programmers are unlikely to recognize (automatic) floor division – try to convince a fifth grader that one divided by two is zero.

 

  

Python is a dynamically-typed language, so there is no declaration of function or parameter types. In the function signature, you see no type requirements at all. Yes, the arguments can be anything; the division operation succeeds as long as the operator is sufficiently overloaded to handle the operands.

 

With classic division behavior, your results with a pair of floats certainly differs from that of sending in a pair of integers whereas the answer will always be correct with true division. To bridge the dichotomy, you must resolve the following intransitivity:

 >>> 1 == 1.0 

 

Those who aren’t programmers are flabbergasted that “one divided by two is not equal to one point zero divided by two point zero!” This equality, however, does work in Python 3 using true division:

 >>> from __future__ import division # 2.2+-only 

  

 

Print statement in Python2.x was a function and it remains a function in Python3.x. The difference is in its syntax. In Python2.x it didn’t met with the consistency model other functions follow. Usually functions have a () to enter the parameters. In Python2.x there was no parenthesis. In Python3.x the parenthesis is a part of syntax.

 

Python2.x                                      Python3.x 

 

Both prints hello world to the screen.

 

 

In Python3.x we get the solution of an arithmetic division as we had expected. As we had expected in the sense, if we divide 1 by 2 we would expect the answer to be 0.5. But in Python2.x we get the answer 0, whereas in Python we get the answer 0.5, the one we expected.

 

Python2.x             Python3.x 

 

Will prints Zero in python2.x Will print 0.0 in python3.x

 

 

In Python3.x we get a new option for range function. We can extract the first term, last term and rest of the list separately. This option was not available in Python2.x. We had to write separate code to extract these values.

 (a, *rest, b) = range(5) 

This code section will generate a syntax error in Python2.x.

 

 

‘<>’ symbol used in Python2.x to represent not equal to is no longer available in Python3.x. If we try it it will generate a syntax error. The symbol ‘!=’ is used instead, which was available in Python2.x along with ‘<>’.