PEP 476 *has* a mechanism in it that was supposed to deal with this problem, thus leaving *end users* in full control of the decision on when they upgrade their security infrastructure rather than having that decision arbitrarily imposed on them by a vendor or an upstream community project regardless of whether or not it's appropriate for their particular situation. Unfortunately, it turned out I was wrong about the viability of the approach in PEP 476, hence this suggestion to revisit the question.

There is *no* suggestion of changing the default behaviour away from that defined in PEP 476, the part I would like to revisit is merely the section on configurability, where the goal is to be able to deploy "All of PEP 476 *except* the change in default certificate verification behaviour". The approach in the PEP works for folks deploying upstream Python directly, and I *thought* it would work for the redistributor case as well. It's the latter point I was wrong about.

This is a level of consideration of their needs that folks are willing to pay for, but it's also an expensive one to provide, so it doesn't make sense for upstream to provide it for free. Rather, I am asking the upstream development community to work with commercial redistributors to come to an accommodation that actually meets end users upgrade needs, rather than leaving them stuck on a legacy Python version with no viable path forward to more secure infrastructure. (Telling end users "just upgrade anyway" when complex systems and large scale deployments are involved doesn't work - this is why Microsoft ended up having to support Windows XP for 12 years)

I thought proposing a useful new feature for Python 3.5 and then proposing a subsequent backport would be the easiest path forward, but I now suspect a PEP specifically targeting an improved network security transition plan for the benefit of folks managing infrastructure upgrades in the 2.7.x series may be a better option.