difference between python 2 and python 3

Python 3.0 was released in 2008. The final 2.x version 2.7 release came out in mid-2010, with a statement of extended support for this end-of-life release. The 2.x branch will see no new major releases after that. 3.x is under active development and has already seen over five years of stable releases, including version 3.3 in 2012, 3.4 in 2014, 3.5 in 2015, and 3.6 in 2016. This means that all recent standard library improvements, for example, are only available by default in Python 3.x. 
If you can do exactly what you want with Python 3.x, great! There are a few minor downsides, such as very slightly worse library support1 and the fact that some current Linux distributions and Macs still use 2.x as default, but as a language Python 3.x is definitely mature and ready for use. As long as Python 3.x is installed on your user's computers (which ought to be easy, since many people reading this may only be developing something for themselves or an environment they control) and you are writing things where you know none of the Python 2.x modules are needed, it is an excellent choice. Also, most Linux distributions have Python 3.x already installed, and nearly all have it available for end-users. One somewhat painful exception is Red Hat Enterprise Linux through version 7: Python 3 does exist in the EPEL repository, but some users may not be allowed by company policy to install anything from such add-on locations - see note on "control" below. Some distributions are phasing out Python 2 as preinstalled default
In addition to the 2to3 tool that allows 3.x code to be generated from 2.x source code, there's also the 3to2 tool, which aims to convert 3.x code back to 2.x code. In theory, this should work even better than going the other direction, since 3.x doesn't have as many nasty corner cases for the converter to handle (getting rid of as many of those as possible was one of the main reasons for breaking backward compatibility after all!). However, code which makes heavy use of 3.x only features (such as function annotations or extended tuple unpacking) is unlikely to be converted successfully. 
The official end-of-life date for the Python 2 series is 2020 which means you have three years of support from the community. After that, you'll have to find ways to get support for this series as new vulnerabilities can always arise. Since 2.7.13 is expected to be the last major release in the 2.7 series, new features won’t be backported, and only security and bug fixes will be going in from now until 2020. (ActiveState will continue to support the Python 2 series for a very long time, but new language features will be only available in Python 3.)

In addition to the reasons mentioned above, you want to move to Python 3 because there have been a lot of improvements in the language. Probably the biggest reason is integer division which is much simpler and stronger in Python 3. Other reasons include asynchronous support, better exception handling, Unicode support, and you can mix tabs and spaces. Python 3 also gives you function annotations and range memory objects which are significantly more memory efficient.

There are Python packages like Six (we ship this package with our ActivePython distribution) that helps companies make that migration, but the nice thing about moving from Python 2 to Python 3 is that the core of the language is quite similar. While there is not too much rewriting, there are items that have to be converted which can be done with the help of migration libraries.

Another issue with moving to Python 3 is that in rare cases the third-party packages that you may rely on aren't available. Make sure you check your packages for compatibility just in case there is a rare show stopper...you want to know that up front.

By making the migration you'll get better performance and new improvements, an active community working on the save version you are on and the community has many helpful resources to help you cross the road to Python 3.
Breaking Bad

Although the direction is very positive and the tide is turning in Python 3's favour, we can't ignore that there has been a lot of resistance in the community to move to Python 3. As soon as you break backwards compatibility it is just hard to get the community to coalesce around the new version. It creates quite a bit of friction and it takes many years to resolve.

The bottom line is IT and development managers don't want their older apps to break if they upgrade them--they are providing value just fine with the old code base. If it breaks, it means they need to find the personnel and budget to fix it. There are a lot of enterprises out there with large codebases created by people who are now long gone...and it's a big deal to assign a resource to upgrade something knowing you take the risk of breaking it. And that's when you get managers in organizations saying, "I just don't want to move versions." They are locked in to the version "forever" (or until they find the application becomes obsolete or the cost to maintain it is greater than the cost to rewrite).

Companies using older versions is not good for the language community because they want to move things along and don't want their language to be known as having large security holes based on these older versions. The community can't continuously be backporting fixes so enterprises must get support to stay on the legacy version or move with the times. The good news is, it is not a rewrite...most of the code will remain the same, and the same great Python developers that built it can be the ones to help migrate it.