Reason 1 : Major Unicode Changes
In Python 3, strings are unicode by default. No big deal, right? Depending on what you’re working on, it might be bigger than you might think. One of the biggest gripes from within the Python community about this change has come from the Flask project. Flask specifically chose not to support 3.0-3.2, but 3.3+ are supported. Using Python 3 could be problematic if you’re not starting a new
project, and are using a bit older version of WSGI. According to the Flask docs (http://flask.pocoo.org/docs/0.10/python3/), “Some of the decisions made in regards to unicode and byte utilization on Python 3 make it hard to write low level code. This mainly affects WSGI middleware and interacting with the WSGI provided information.” If you need to work on a project that requires Flask, you might want to use Python 2 until the main documentation for WSGI becomes more fluidly written about Python 3 to save a bit of a headache.
If you’re a user of Django, you’re likely familiar with a high level of adoption on the part of the Django project of preparing for Python 3. If you’re using Django on an existing project that was built using Python 2, there might not be a need to port to Python 3 just yet, though. According to the 1.8 docs for porting to Python 3, there are some code changes necessary to implement the back-support of Python 2 through the latest version.
Reason 2 : The Incompatible Libraries
There are still a large number of Python libraries that are not yet compatible with Python 3. If you’re eager to be an early adopter & okay with working through new issues with Python 3, it might be for you, but you may want to rethink if the library you’re using doesn’t yet support it. There’s a list of libraries colored by support or not support for Python 3 here: https://python3wos.appspot.com/. One notable item for those in the devops world is Ansible. Ansible has become an extremely powerful library for managing build & release processes, automating devops tasks, & more. The ability to have confidence in builds & deployments is extremely important, especially in environments with releases and builds occurring often. Don’t break the build! Another notable library is MySQL-Python. If you’re running systems in production using this library, it may be a good idea to wait until there is full Python 3 support there before switching.
Reason 3 : Production Risk vs. Reward – When “Move Fast & Break Stuff Isn’t Your Mantra”
We’ve all heard the Facebook mantra of “move fast & break stuff”, but for many Pythonistas, that’s not a great mantra to follow. It’s important that production systems are stable, that code is as close to bug-free as we can keep it, and that issues are easy to find. If you’re starting a greenfield project , Python 3 might be a great idea, but for projects that have been written & maintained in Python 2 for a long period of time, the overhead level of making the switch can increase dramatically. For major organizations with large user bases, making this change can and, in many cases, should be a very slow process. Even for the current organization of Guido Van Rossum (Dropbox), one of the leaders of the Python community & original creator of the language, the switch has not been made.
Reason 4 : More machines have 2.x installed by default
As a user of Ubuntu as a production server, Python 3’s recent changes won’t mean that Python 3 will be the default Python at /usr/bin/python. The Ubuntu project itself has noted that making a switchover to all of the project goals for Python 3 default support is in fact a “daunting” task, so waiting might be in the best interest of the production environment you are seeking to run. When running Python programs on a server that don’t have a need for Python 3’s new features are want to avoid some of the other problems discussed, stick to Python 2 here & it will be a much safer bet, but let’s try not to make bets when developing software!
Reason 5 : Annoyance with print statement changes
This is pretty much the most noticeable to an average Python user when switching between consoles. You need to use “print(‘foo’)” instead of simply “print ‘foo’”. If switching between different Python environments, this can become more than a little bit annoying if you’re simply trying to do some basic debugging or even show a tutorial.
