On 10 Sep 2014 02:11, "Christian Heimes" email@example.com wrote:
On 09.09.2014 05:03, Nick Coghlan wrote:
On 9 Sep 2014 10:48, "Jim J. Jewett" <firstname.lastname@example.org mailto:email@example.com> wrote:
I assume that adding _unverified_urlopen or urlopen(context=...) do provide incremental improvements compatible with the eventual full opt-in. If so, adding them is probably reasonable, but I think the PEP should explicitly list all such approved half-measures as a guard against API feature creep.
From Guido's and your feedback, I think we may need two things to approve this for 3.4.2 (putting 2.7 aside for now):
- "context" parameter support in urllib.request (to opt out on a
per-call basis) 2. a documented way to restore the old behaviour via sitecustomize (which may involve monkeypatching)
What's with our plan to introduce sslcustomize? Is the idea for a configuration module and named contexts off the table?
I'd still like to do that for 3.5+ as the proper long term fix, but I don't think it's necessary for 2.7 or 3.4.
I came up with the idea to introduce the module "sslcustomize" similar to sitecustomize. Contrary to sitecustomize the module is imported at the end of the ssl module.
Based on my idea Nick proposed another addition to the SSL module. He proposed a ssl.named_contexts mapping from module names to factory functions that create SSLContext objects. http://permalink.gmane.org/gmane.comp.python.devel/149292
I still prefer the general idea over the monkey patching idea because it provides a clean but simple interface for structured configuration. Monkey patching of stdlib modules is ugly and error-prone.