On 31 May 2015 at 09:20, Larry Hastings
On 05/30/2015 07:26 AM, Toshio Kuratomi wrote:
Porting performance features from python 3 to python 2 has the disadvantage of cutting into a compelling business case for users to move forward to python 3.[1] so doing this has a cost to python 3 adoption. But, the question is whether there is a benefit that outweighs that cost. [...]
Backporting performance enhancements from 3 to 2 does seem to be counterproductive from the perspective of the Core Dev community. But certainly in this case, when Intel drops a major bundle of working code in our collective lap, it absolutely feels like the right thing to me to check it in and support it. And happily the Python Core Dev community generally does the right thing.
There's another benefit that I didn't think to mention earlier, which is that getting folks from Python 2 -> Python 3 isn't actually my major version adoption concern at the moment: I'm more interested in how I can persuade them to stop using Python *2.6*, which is still a higher proportion of PyPI downloads with an identifiable client version than Python 3 [1], and the relative proportions between them are likely to be even worse once we start venturing inside corporate firewalls where direct downloads from PyPI aren't permitted. While I suspect barriers to migration at the distro level carry a fair bit of the blame there (and we're working on those), performance improvements in the 2.7 branch help provide an additional carrot to assist in that process, complementing the stick of trying to educate the community at large that it's unrealistic and exploitative [2] for folks to expect free community support for versions of Python that are so old that not even the core development team support them any more (i.e. Python 2.6 and earlier). My one consolation is that the Python community are far from alone in struggling to win that fight against institutional inertia once folks have widely adopted a version of a product that "works for them". My theory is that folks will pay to be able to keep using these older systems because our industry doesn't have very good tools for quantifying the cost of the technical debt incurred by attempting to maintain the status quo in the face of an evolving ecosystem. As infrastructure change management practices improve (e.g. through ideas like Holistic Software's hybrid dynamic management [3]), and not only the platform level tools but also the related business models evolve to better support those approaches, I'm hoping we'll see things change for the better not just in terms of Python in particular, but in terms of institutional infrastructure as a whole. Cheers, Nick. [1] https://caremad.io/2015/04/a-year-of-pypi-downloads/ [2] http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html [3] http://www.holistic-software.com/hybrid-dynamic-model -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia