On 28 May 2015 at 18:54, Berker Peksağ <berker.pek...@gmail.com> wrote: > On Thu, May 28, 2015 at 3:17 AM, Parasa, Srinivas Vamsi > <srinivas.vamsi.par...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
