On 07/21/2014 03:26 PM, Victor Stinner wrote:
The PEP is accepted.
Thanks, Victor!
Congratulations, Ben!
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.pyt
On 24 Jul 2014 05:37, "Alex Gaynor" wrote:
>
> 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 sock
Antoine Pitrou python.org> writes:
>
> You mean for use with SSL_set_app_data?
Yes, if you look in ``_servername_callback``, you can see where it uses
``SSL_get_app_data`` and then reads ``ssl->Socket``, which is supposed to be
the same object that's returned by ``context.wrap_socket()``.
A
Le 23/07/2014 15:36, Alex Gaynor a écrit :
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
Antoine Pitrou 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 s
