The discussion isn't on python-ideas yet because I wanted to get a better sense of what might be politically feasible before putting this question to a broader audience. I agree it needs to move there eventually (likely during or after PyCon), and will almost certainly lead to a PEP (3.5b1 is slated for late May, so we have 6-7 weeks to resolve the question in time for that if anything is going to change for 3.5)

To be absolutely clear, nobody is thinking of reintroducing silent security failures anywhere - the ultimate aim of posting this draft patch is to start down the path to defining a new Python 3.5 feature that could then by pitched for a PEP 466 style backport to Python 2.7 to provide a potentially smoother upgrade path from the pre-PEP-476 status quo to the shiny new PEP 476 future for the benefits of folks that take both security concerns and backwards compatibility concerns at least as seriously as python-dev do, but are serving a very different audience and hence may need to make different trade-offs between these considerations.

The "use sitecustomize.py to monkeypatch in the old behaviour" section in PEP 476 was *intended* to provide that upgrade path, but it turned out not to work as well as I hoped it would as it turns out that approach effectively requires forking the standard library to let a vendor manage the migration on behalf of their customers by offering a bridging "opt-in" period. Changing the standard library's behaviour to this degree would be a genuinely drastic option, so I consider it vastly superior to backport a supported behaviour from a later version of Python (along the lines of the network security backports in PEP 466) than it would be to invent something custom that has no upstream support.

This does mean spending more time upfront coming up with a way of designing the feature that the core development community considers to be useful independently of backporting considerations (e.g. bringing the STARTTLS migration into the framework could be useful, as the sad state of email server certificate validity means that even upstream CPython is going to need to leave that off by default for the time being). That additional time investment is likely to be worthwhile when the pay-off is avoiding a long-lived behavioural fork.

As for *why* such an opt-in bridging period might be needed by some organisations, one of the key issues to consider is the likely desire to do a global upgrade to an updated Python version as soon as possible, *without* risking breaking currently "working" services in an end-user visible way, and then handling the security configuration change on a service-by-service basis as a subsequent step, in conjunction with any necessary upgrades to the related security infrastructure.

Splitting the two activities (Python upgrade, service network security upgrade) this way is potentially desirable even if you have control of all of the affected Python applications, but it may be absolutely essential if you're running a proprietary bytecode-only Python application in the system Python, or simply aren't authorised to make application level changes to an affected service.

The rationale for introducing a configuration or marker file for this is to allow the *default* behaviour in the absence of such a file to be the standard PEP 476 behaviour. An opt-in bridging period can then be implemented by publishing a default configuration file that globally opts out, with system administrators selectively opting in.

Eventually the default configuration can potentially be changed or removed such that certificates are verified by default, by which time services that genuinely need to be opted out should already have the appropriate configuration settings set.