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 periodically check my requirements.txt's and there's still a few big holdouts left.
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.
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.
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:
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.
Newer and Better is a totally different question and this is why we have the Python 2 or 3 debate.
Python 3's library is growing all the time and in my opinion already has all the libraries or bindings you'll need right now.
For the rest, it depends on the libraries you need...