On 24 February 2017 at 20:21, Cory Benfield <c...@lukasa.co.uk> wrote:
> > Either way, I think I’d like to confirm this works by writing two more > modules. First, I’d like to actually write most of the tls module into > something that can live on PyPI, in no small part because backporting it > would be useful for tools like urllib3. Secondly, I’d like to write a shim > for the standard library ssl module so that I have a clearer picture of > whether we want to shim it in Python code or whether we should take this > opportunity to write new bindings to the C code. > > The goal here, essentially, is to have a PoC that the API is at least > suitable for tools like urllib3/requests before we commit to it too much, > and the best way to do that is to prove that the stdlib can meet that API > and that at least one other implementation can do as well. I’ll use > SecureTransport for that proof point, but I’ll make available a branch of > urllib3 that has patches applied to use the new API so that anyone who > wants to investigate shimming a different TLS implementation has got a test > suite they can try to run. > > Obviously that’s slightly orthogonal to PEP acceptance, but I wanted to > keep people up-to-speed with my thinking. > Having a sufficiently complete reference implementation in place to convince both the author(s) and the reviewers that the proposal solves the problem it claims to solve is part of the PEP process, so your planned approach makes a lot of sense to me. Cheers, 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
