On 08Jun2017 1237, Donald Stufft wrote: > > The basic yak stak here is: > > * PEP 543 should be the future, it is a much much better way of handling > TLS than our current ssl module is. > * Cory can’t spend his work time on PEP 543 unless he can say it is > useful for requests. > * In order for PEP 543 to be useful for requests, he needs a way to > provide a backport for it for Python 2.7. > * This backport *CAN* be OpenSSL only, but needs to be able to > provide the same API. > * PEP 543 wants to work with MemoryBIOs instead of sockets, because a > MemoryBio is a much much better way of implementing this problem for a > variety of reasons, and it would be a mistake to use a socket primitive > again. > * Indepently, requests also wants to be able to provide the ability for > people to use it with asyncio, however it can’t drop support for Python > 2.7 in the quest for doing that. Twisted provides a way forward that > lets requests work on both 2.x and 3.x and integrate with asyncio, but > Twisted requires MemoryBio to do so. > * pyOpenSSL *could* be used to provide the MemoryBio needed on 2.7 for > both cases from up above, however, pip cannot depend on a C library that > isn’t part of the standard library - in addition this would break > alternative runtimes like Jython where pyOpenSSL doesn’t work. Awesome, this is exactly what I needed to see. What if Python 2.7 just exposed the OpenSSL primitives necessary so that ctypes could use them? Is that a viable approach here? Presumably then a MemoryBIO backport could be pure-Python. It doesn't help the other *ythons, but unless they have MemoryBIO implementations ready to backport then I can't think of anything that will help them short of a completely new API. Cheers, Steve
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4