[Python-Dev] Computed Goto dispatch for Python 2

[Nick Coghlan]

On 28 May 2015 at 18:54, Berker Peksağ <berker.peksag at gmail.com> wrote:
> On Thu, May 28, 2015 at 3:17 AM, Parasa, Srinivas Vamsi
> <srinivas.vamsi.parasa at intel.com> wrote:
>> Attached is the computed goto patch (along with instructions to run) for Python 2.7.10 (based on the patch submitted by Jeffrey Yasskin  at http://bugs.python.org/issue4753). We built and tested this patch for Python 2.7.10 on a Linux machine (Ubuntu 14.04 LTS server, Intel Xeon – Haswell EP CPU with 18 cores, hyper-threading off, turbo off).
>
> Hi Vamsi,
>
> Thank you for your work and your detailed email.
>
> I'm -1 on the idea because:
>
> * Performance improvements are not bug fixes

The "nothing except backwards compatible bug fixes in maintenance
releases" rule was adopted for the *benefit of Python users*. When a
new feature release can be reliably expected every 18-24 months, it
makes sense to err heavily on the side of minimising risks to
stability when it comes to making judgement calls on whether or not a
change is appropriate to a maintenance release or not.

Python 2.7 is an unusual case, as even though there *are* newer
feature releases available, the barriers to migration are much higher
than they would otherwise be. Each progressive 3.x release has brought
those barriers down a bit, and 3.5 and the static type checking work
being done through mypy et al will bring them down even further, but
version migration work is still work where end users don't see any
immediate practical benefit - they only see the benefit *after*
they're able to drop Python 2 compatibility, and can start using
Python 3 only features like matrix multiplication and the async/await
syntax.

*Adding* features to Python 2.7 is quite rightly still controversial,
as they add complexity to the compatibility matrix for testing
purposes. Code that runs correctly with the PEP 466 and 476 changes to
SSL handling, may fail on earlier versions.

Internal performance improvements, by contrast, don't hurt end users
at all beyond the stability risks, and in this case, the request to
make the change is being accompanied by the offer to assist with
ongoing maintenance (including engaging an experienced core developer
to help coach Intel contributors through the contribution process).

So when folks ask "What changed?" in relation to this request, what
changed is the fact that it isn't expected to be a one off
contribution, but rather part of a broader effort focused on improving
the performance of both Python 2 and Python 3, including contributions
to ongoing maintenance activities.

> * The patch doesn't make the migration process from Python 2 to Python 3 easier
> * In long term, it would be nice to work on making Python 3 better:

Indeed, but we also need help living up to the "Python 2.7 will be
supported to 2020" commitment. Python 2.7 maintenance is *not* a
particularly exciting task, and it's only going to get less
interesting as Python 3 adoption climbs, so we're going to need paid
contributors to start filling the gap as volunteers (quite reasonably)
move on to the more inherently rewarding task of working to move
Python 3 forward.

That's going to be a negotiation process - companies don't typically
contribute paid development time to open source projects out of the
kindness of their hearts, they do it either because they're using the
project themselves, because of deals they've made with individual
contributors around how they spend their time, or because it helps
them influence the direction of upstream development in ways that help
them and their customers. (And sometimes it's a mix of all 3 of those
factors)

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia