We quickly saw the benefit of wrapping socket methods in the SSL.Connection class, for an easy transition into using SSL. The problem here is that the socket module lacks a C API, and all the methods are declared static. One approach would be to have OpenSSL as a submodule to the socket module, placing all the code in socketmodule.c, but this is obviously not a good solution, since you might not want to import tonnes of extra stuff you're not going to use when importing the socket module. The other approach is to somehow get a pointer to the method to be called, either the C function, or a callable Python object. This is not really a good solution either, since there's a lot of lookups involved.
We chose to take the second approach, making the module standalone, and the current solution is when creating an SSL.Connection object, you have to supply it with a socket object. Once and for all, all the methods are found with PyObject_GetAttrString() and stored in the C datatype representing the class.
A future change might be to drop this behaviour and instead call PyObject_GetAttrString() from the getattr() function corresponding to the SSL.Connection object, if the method is not found locally. This has the advantage of being forward compatible, and that you don't necessarily need sockets as the transport layer! However, it does represent a problem, in that the transport layer object must have connect() and accept() methods following the format of the socket objects, even though they may not fit semantically. In conclusion, what we have now works for socket, and nothing else. In the future it would be nice to have other transport layers, but we'll deal with those problems at that time.