4 ms·
In fairness to those developers (of which I was one): Python 3 was released a decade ago, and support for Python 3 in commonly used libraries was released, depe
by danudey 7y ago
In fairness to those developers (of which I was one): Python 3 was released a decade ago, and support for Python 3 in commonly used libraries was released, depending on the library, some time between a decade ago and "not yet".
This has required a lot of engineering work to make libraries function with Python 2 and Python 3 (e.g. pandas, numpy, scipy), to make frameworks work properly on both (e.g. django), and to ensure that the libraries that everything relies on (e.g. mysqldb) get updated, forked, or replaced with rewritten alternatives.
Sure, I as a developer "should have" been writing Python 3 for the last ten years, but for most of those years it would have required rewriting large libraries that I, and other developers, rely on to be productive.
Unfortunately this has meant that instead of starting Python 3 projects over the last ten years, people have been starting Python 2 projects so that they could get their work done in those intervening years.
- TylerE 7y agoEven ignoring the lib issue, there were major performance regressions. Py3 didn’t really become clearly better until at least 3.4.
- melling 7y agoThat was 5 years ago. I don’t do a lot of Python, and have been exclusively using v3, but I thought you could make your Python 2 somewhat compatible with v3 by using libraries, etc. How close can you come to a Python code base that runs in v2 and v3?
- joshuamorton 7y ago> How close can you come to a Python code base that runs in v2 and v3? Using the `six` module, this is (nearly) trivial for 99% of code. If you're doing certain weird things, its more difficult but possible. (I say this having done py2-3 conversion or dual support for lots of vanilla code, as well as a significant amount of weird code: c/c++ extensions and code that uses advanced features like code object introspection and dynamic imports/rewriting/etc).
- tingletech 7y agoI have some libraries I maintain with `six` -- I find it like writing in a whole new dialect (neither 2 nor 3). I moved to futurize for some libraries -- its like writing python 3 that will run on python 2. I am looking forward to dropping python 2 support on libraries I maintain.
- TylerE 7y agoThe problem is when your devs are spending 100% of time, or close to it, on work clients are paying for, it's really hard to spend time porting. Porting isn't really as trivial as you make it sound, either.
- tingletech 7y agoIf it ain't broke, why fix it?
- TylerE 7y agoPretty much.
- _bxg1 7y agoThis just means there was a network effect amplifying the general reluctance; there may have been a greater impetus on the library developers than the end-users, but the community as a whole still failed to prepare for the future.
- alfalfasprout 7y agoNot to mention getting recent version of Python 3 easily usable in enterprise linux distros is a fairly recent trend.
- takeda 7y ago> Unfortunately this has meant that instead of starting Python 3 projects over the last ten years, people have been starting Python 2 projects so that they could get their work done in those intervening years. Joke on them, some extensions you listed didn't even wait until 2020 and already dropped Python 2 support.
- flukus 7y agoOn the plus side it does serve as a powerful reminder of the costs and technical debt incurred by dependencies and why they should be minimized as much as practical. We've got some projects based on abandoned libraries that will never be upgraded to python 3, essentially leaving us paralyzed on python 2. These projects were also meant to be deprecated a decade ago so no path forward was ever created, but they cling on to dear life.