Sure legacy projects still need support and for that they get the 1.11 LTS, but otherwise it's really time to move on.
Sure legacy projects still need support and for that they get the 1.11 LTS, but otherwise it's really time to move on.
The only reason why it might be hard is you are unfamiliar with the extension's code and/or C
Practical example: https://github.com/zopefoundation/BTrees/blob/master/BTrees/... https://github.com/zopefoundation/BTrees/blob/master/BTrees/...
There are a couple #if PY3K, but not much, really.
I ported a bunch of extension modules, total a couple thousand LOC, and it was pretty much a matter of reading the docs (see guide at https://docs.python.org/3/howto/cporting.html ) and adding a few #ifs. Total time maybe an hour or two.
One possible solution would be to offload this work into a celery worker which can call python2 as necessary.
Release Date: 2014-12-10
Replacing hot spots with C is a tried and true tactic. I don't see how django would substantially change that equation.
Making code compatible with python2.7 onward means that you can't use any new features from 3+ and the code is plain ugly, I don't know if you wrote 2/3 compatible code, it is not as enjoyable to do.
I think Django's approach where the LTS will still work on 2.7 (and LTS is for 3 years, which is until python2 itself stop being maintained) is fair.
You still have 3 years to fix things and if you want to use latest Django and be cutting edge, you probably should use latest Python as well.
Except that there are still some critical packages that aren't on Python 3 yet. Not to mention a lot of functionality breaks even if the libraries do exist, which means you have to code things up quite differently sometimes.
We ended writing a service in PHP to use Google's APIs, and are mostly using Scala or JS instead of Python for the Lambda services because this project is basically a ton of unicode mangling, and you can pry Python 3's sane unicode support from my cold dead hands! But the libraries still aren't totally perfect. It just takes on dependency being out of date to screw your plans.
https://github.com/google/google-api-python-client/
I see only one Py3 bug is the open issues. And I think even their ancillary library Python Flags is now officially Py3 compatible, even though there has been a Py3 fork of it for years.
I didn't mean the one literally called google-api-python-client though (forgot they had that, ha). The googleads-python-lib is the critical one for me. PyPI says it supports 3+, but do one search in the repo for "print" and you'll see that's clearly not true.
Looking through the history, seems like they've claimed support for it for a while. We've tried it twice and had issues both times, though I never tried it in Py2, so maybe it just has problems in general.
There's a "hack" of running Python 3 on AWS Lambda via subprocess until it's officially supported.
http://stackoverflow.com/questions/36143563/using-python-3-w...
Included in the list: nodejs, chromium, trac, bugzilla, bazaar
[citation needed]
Pretty much all critical packages now work on 3, as witnessed by the Wall of Superpowers.
Maybe some django-specific lib is still 2-only? In which case, rewrites/forks should be relatively trivial and I'm even happy to have a look myself.
https://python3wos.appspot.com/
almost everything on the list has gone green now
2) Let's see some proof of your argument, because many packages and platforms are happily supporting Python 3 now. Put your money where your mouth is.
If in half a decade things haven't been ported there are more serious issues.
How about millions of lines of code in your company in Python 2, and several Python 2 based services and websites?
Why on earth will you go to Python 3 at huge rewriting costs? To get some fancy syntactic sugar and improved unicode?
And the latter doesn't work so well thus far for Python 3.
If you're starting a brand new Django project you're not rewriting anything. If you're rewriting something, it's not really new.
My company is a Django shop and while we have no intention of upgrading Python 2.x codebases to 3, we do start all our new projects on Python 3. It just doesn't make sense not to do it.