5 ms·

Because of legacy, but these days there is no reason not to use python 3 on new projects. Note that Python 2.x will no longer be supported in 2020.

drdaeman 11y ago
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.)
- dorfsmay 11y ago
  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.
  - tedmiston 11y ago
    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 https://caniusepython3.com every few months though.
tedmiston 11y ago
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/ http://py3readiness.org/
- zardeh 11y ago
  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.

drdaeman 11y ago

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.)

dorfsmay 11y ago
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.
- tedmiston 11y ago
  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 https://caniusepython3.com every few months though.

tedmiston 11y ago

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/ http://py3readiness.org/

zardeh 11y ago
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.