There is no advantage to 2 unless you're using a legacy environment or a legacy dependency.
Edit: the "Python 3 Wall of Superpowers"[1] is a good resource for seeing how far the ecosystem's conversion to Py3k has come. Many of the "red" packages even have Python 3-compatible forks (e.g., Supervisor).
I know that python3wos is out of date regarding the libraries people actually use. When I look at the py2-only libraries on there, I see:
- the big "legacy dependencies", Twisted and gevent
- libraries that are ported but the site doesn't know it, such as protobuf
- highly specific code to extend a particular system, such as tiddlywebplugins
- system utilities that it doesn't matter what language they're in, such as supervisor and Fabric
- libraries that have been abandoned (in all versions) and superseded, such as MySQL-Python
I'm not saying you're wrong, I'm saying that we need a better python3wos. It makes it look like "unless you bet on a massive legacy asynchronous framework, you're fine".
I think that to some extent this should be the case, but to some extent, there are things that should be ported that we're not seeing because of the unrepresentative set of packages on python3wos.
Twisted is one, and it's there partly because a lot of code relies upon it, not because I like it. I also use a few niche libraries which haven't been bumped and there's a few libraries like mechanize too - not so niche yet still not bumped.
Honestly, if there were some big incentive at this point I would go through the hassle of upgrading, but there isn't. The gains on python 3 seem relatively minor and incremental.
The only major reason to use 2 instead of 3 is library support, however a lot of good libraries still aren't updated to Python3, such as the google-api-python-client, gevent, scrapy, the list is getting smaller every day though. There are a few other reasons, but they're pretty uncommon/advanced, and not something new users will encounter [0].
Python 2 gets many of Python 3's features back-ported (they can be enabled with an import statement), which is really convenient when working with 2, but it also helps contribute to the lack of a migration from 2 to 3.
Python 2 and 3 are very similar though, and most projects can even run under either 2 or 3 with the exact same codebase. So it doesn't take much effort (or none at all) to move a project from 3 down to 2 while still in early development if requirements necessitate.
[0] One example that comes to mind is a difference in the way str.format() works. In Python 3, strings are unicode text objects, in Py2, they are bytestrings. Some projects used str.format() in Py2 to format binary data rather than text, which breaks when moving to 3. Porting a compatible change to Py3 has been rejected several times because of the complexities in implementation, as well as it being unidiomatic to the language. See:
It depends on your problem domain. If it's Ansible-related for example, you go with 2. If it's web related, 2 is a good default, as those are still the most tested code paths. If it's scientific, go with 3, most of those tools are newer.
If it's scientific, go with 3, most of those tools are newer.
Which tools? I use python for scientific computing and I can't think of any tool that I use where the python 3 version (if it exists) is newer/better than the python 2 version.
I only knew they were in active development and supposed that's were the action is, it's not my area at all. Most scientific use is also with version 2 then. Then I can't think of any problem domain were you should go with version 3 in practice. I would be interested in what the other recommendations here are based on, other than "I like it for my own stuff".
If you need unicode (i.e. your app will take more langauges than english and spend a lot of time on that (hint! GUI hint!), the 3 is the way to go. Unicode support is so much better...
For the rest, it depends on the libraries you need...
Edit: the "Python 3 Wall of Superpowers"[1] is a good resource for seeing how far the ecosystem's conversion to Py3k has come. Many of the "red" packages even have Python 3-compatible forks (e.g., Supervisor).
[1]: https://python3wos.appspot.com