[Python-Dev] 2.7 is here until 2020, please don't call it a waste.

Nick Coghlan ncoghlan at gmail.com
Sun May 31 07:23:49 CEST 2015


On 31 May 2015 at 09:20, Larry Hastings <larry at hastings.org> wrote:
> 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 at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list