Should <NetworkingBackend>.start_tls()
be an in-place interface?
#710
tomchristie
started this conversation in
General
Replies: 1 comment
-
I'm not convinced that this is a genuinely valuable piece of work for us to undertake, or that the API is necessarily "better" so my suggestion would be that we leave it as it currently is. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Pull request #699 adds the networking backends to the public interface.
This is a follow-up that reviews one part of the interface.
The question is if we would like to change the interface of
start_tls()
, so that the following example from the docs...Would instead become this...
...
There is also an example in the
network_stream
extension docs...Which would instead be this...
This would be in-line with
start_tls
from Python's asyncio stdlib interface.There's a few different existing API styles out there - Trio and AnyIO use "instantiate a new wrapper class" style. The synchronous stdlib uses
ssl.wrap_socket
.Having the
.start_tls
be a method on the network stream seems convenient for our interface, so I'd suggest we stick with it.But should it be an in-place operation?
Beta Was this translation helpful? Give feedback.
All reactions