On 10 Sep 2014 02:11, "Christian Heimes" <christian@python.org> wrote:
>
> On 09.09.2014 05:03, Nick Coghlan wrote:
> >
> > On 9 Sep 2014 10:48, "Jim J. Jewett" <jimjjewett@gmail.com
> > <mailto:jimjjewett@gmail.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):
> >
> > 1. "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.

Cheers,
Nick.

>
>
> For reference:
>
> 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.
>
> Christian