Re: [Python-Dev] [PEP466] SSLSockets, and sockets, _socketobjects oh my!
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 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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEP466] SSLSockets, and sockets, _socketobjects oh my!
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 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. You mean for use with SSL_set_app_data? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEP466] SSLSockets, and sockets, _socketobjects oh my!
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()``. Alex ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEP466] SSLSockets, and sockets, _socketobjects oh my!
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 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? Wearing my "risk management" hat, option 1 sounds significantly more appealing than option 2 :) Cheers, Nick. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 471 "scandir" accepted
On 07/21/2014 03:26 PM, Victor Stinner wrote: The PEP is accepted. Thanks, Victor! Congratulations, Ben! -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
