ZestyBeanz Technologies Pvt Ltd 4th Floor, Nila, Technopark Thiruvananthapuram,
India – 695581
Phone: +91 471 4063254
Fax : +91 471 2700171


ZestyBeanz Technologies Pvt Ltd
61/3236, Manikkath Cross Road
Ravipuram, Kochi, India - 682016
Phone: +91 484 4063254


Zesty Labs
Office # 2003, Millennium Plaza Building
Sheikh Zayed Rd, Dubai, UAE
Phone: +971 4333 2222​
Mobile: +971-52-7553466


ZestyBeanz Technologies GmbH
Reuterstraße 1
90408 Nürnberg
Fon: +49 911 4801 444
Fax: +49 911 4801 445

Python 3.x vs Python2.x

Contact Form

Arif's picture

Python 3.x vs Python2.x

Here I am trying to list some of the differences between Python3.x and Python2.x. Only those differences which I came through are listed. I expect more differences as I go deep into Python3.x. Python3.x is a backward incompatible Python release. i.e codes written in Python2.x may or may not run in Python3.x and vice versa.
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.
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.
Classic Division
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) 
>>> 1.0 / 2.0 # returns real quotient (true division) 
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:
>>> from __future__ import division # 2.2+-only  
>>> 1 / 2 # returns real quotient 
>>> 1.0 / 2.0 # returns real quotient
Floor 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.
>>> 1.0 // 2.0 # floors result, returns float
>>> -1 // 2 # negatives move left on number line
Classic vs. True Division
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.
One example the proponents use to convince others is the following function:
def velocity(distance, time): 
rate = distance / time
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 
>>> 2 == 2.0 
>>> 1 / 2 == 1.0 / 2.0 # classic division 
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 
>>> 1 / 2 == 1.0 / 2.0 # true division 
>>> 1 // 2 == 1.0 // 2.0 # floor division 
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 
print 'hello world'     print('hello world')
Both prints hello world to the screen.
Arithmetic Division
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 
1/2          1/2
Will prints Zero in python2.x Will print 0.0 in python3.x
Range Function
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) 
print (a) 
[1, 2, 3]
This code section will generate a syntax error in Python2.x.
Not Equal To
‘<>’ 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 ‘<>’.