4 ms·
What if you have a gigantic Python 2 codebase?
by sigjuice 9y ago
What if you have a gigantic Python 2 codebase?
- kstrauser 9y agoThat's a different but unrelated problem. In that situation, consider that official support is almost over for Python 2 and extended support from third party vendors is going to get nothing but more expensive with time. It will be harder to maintain those projects as the dependencies they use drop support for an increasingly obsolete release. It will become much harder to hire great engineers willing to work on legacy versions. Basically, Python 2 is going to become a very serious technical debt very soon. It's past time to start paying that down.
- theptip 9y agoYou've only got 2 years, get started now! If you need to do it gradually (as would be wise for a gigantic codebase), start using `six` to make your codebase forwards-compatible. Then when all your tests pass on python3, cut over, and remove `six`. (Or take a gamble on Google taking over support for Python2 when it officially goes EOL, I suppose).
- sigjuice 9y agoRedhat (or someone like them) might keep the lights on for Python 2 if a large enough customer leans on them.
- kstrauser 9y agoThere's approximately zero chance that RedHat will support backports of huge, many-contributor projects like NumPy or Django that are dropping Python 2 support (see: https://docs.scipy.org/doc/numpy/neps/dropping-python2.7-proposal.html https://docs.scipy.org/doc/numpy/neps/dropping-python2.7-pro... and https://docs.djangoproject.com/en/2.0/releases/2.0/ https://docs.djangoproject.com/en/2.0/releases/2.0/). They just can't - there aren't enough hours in the day. Five years from how, you don't want to be explaining to your CEO why it's literally impossible for you to integrate with a third party SDK because your stack is so ancient and petrified that new code can't incorporate it.