Antoine Pitrou <antoine <at> python.org> writes: > No, IIRC there shouldn't be a cycle. It's just complicated in a > different way than 3.x > > Regards > > Antoine. >
Indeed, you're right, this is just differently convoluted so no leak (not that I would call "collected by a normal GC" a leak :-)). That said, I've hit another issue, with SNI callbacks. The first argument to an SNI callback is the socket. The callback is set up by some C code, which right now has access to only the _socket.socket object, not the ssl.SSLSocket object, which is what the public API needs there. Possible solutions are: * Pass the SSLObject *in addition* to the _socket.socket object to the C code. This generates some additional divergence from the Python3 code, but is probably basically straightforward. * Try to refactor the socket code in the same way as Python3 did, so we can pass *only* the SSLObject here. This is some nasty scope creep for PEP466, but would make the overall _ssl.c diff smaller. * Some super sweet and simple thing I haven't thought of yet. Thoughts? By way of a general status update, the only failing tests left are this, and a few things about SSLError's str(), so this will hopefully be ready to upload any day now for review. Cheers, Alex PS: Please review and merge http://bugs.python.org/issue22023 :-) _______________________________________________ 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
