New projects depends on that legacy - in form of existing libraries. So, one may find themselves writing somewhat more code than they had expected, either as a new libraries or patching the existing ones to work with Python 3.

Well, not that doing so is a bad thing - it's the contrary, esp. if the patch goes to the upstream - but still this may be frustrating to some.

(Most common libraries are actually work pretty well with Python 3. But there are still a lot of stuff PyPI that's Python 2-only at the moment.)

This used to be an issue, but, in the past 2 years pretty much all the most used libraries have added a python 3 version.

I wish I could say this about our dependencies but it's not quite true yet.

I do run our requirements.txt through https://caniusepython3.com every few months though.

There are a good amount of dependencies that haven't been ported to 3 yet. Using one of these directly, or as a secondary dependency, is the reason running 3 in prod is impractical for many of us.

http://py3readiness.org/

So, ndg-httpsclient, mrjob, numpy, scrapy, monotonic and possibly others do have python3 compatibility.

Then there's a bunch of deployment tools like ansible, fabric, and marionette which don't really need to be python3 compatible for use.

Then there's tools like MySQL-python, python-gflags, python-cjson, INITools, filechunkio, which have python3 compatible alternatives, often in the standard library.

That brings the total up to 331

That leaves basically 3 categories of things left: mozilla tools, database connectors (many of which probably have python3 bindings though I haven't looked), and single sign on tools. Those account for 12 of the remaining 29 libraries.

That's pretty ready.