Thanks Antoine. See my comments below:

> - is it necessary to start exposing server_hostname, server_side and pending()?

At the C level I need server_hostname and server_side exposed because they are needed to implement the cert check in do_handshake(). SSLObject gets a C-level _SSLSocket passed to its constructor and doesn't create it itself. So it can't store these attributes.

At the Python level SSLSocket already had these, albeit undocumented, so that's why I added them to SSLObject as well.

We can leave these undocumented at the Python level if you prefer.

> - SSLObject is a bit vague, should we call it SSLMemoryObject? or do you expect we may want to support other kinds of BIOs some day?

OpenSSL calls the struct just "SSL" which I think is even less descriptive. I think the best description in words is an "SSL protocol instance", however SSLProtocolInstance looks a bit too long to me. Maybe just "SSLInstance", would that be better than "SSLObject"?

I don't think we want to tie the name to the Memory BIO as I think that it may be useful some day to support other BIOs notably the Socket BIO. I believe that the overall _ssl/ssl code could be simplified by:

 - Making SSLSocket inherit from SSLObject and socket.
 - Remove all socket handling from _ssl and use a Socket BIO instead.
 - Implement the blocking semantics for do_handshake(), unwrap(), read() and write() at the Python level.

For testing and benchmarks, the null BIO might be useful as well.

> - should the basic implementations in SSLObject be shared (using some kind of mixin) with SSLSocket, or is it unpractical to do so?

It's possible but I am not sure it would simplify the code a lot. For example, there's no notion of a "closed" or an "unwrapped" socket in SSLObject. If you look at the "cipher" method for example. This is how it looks for SSLSocket:

    def cipher(self):
        self._checkClosed()
        if not self._sslobj:
            return None
        else:
            return self._sslobj.cipher()

And this is how it looks for SSLObject:

  def cipher(self):
      return self._sslobj.cipher()

To use SSLObject as a mixin it would have to be aware of these two uses of its subclasses. It could be done but I don't think it's 100% clean either.