diff options
| author | Jim Mussared <jim.mussared@gmail.com> | 2021-08-12 13:59:29 +1000 |
|---|---|---|
| committer | Damien George <damien@micropython.org> | 2021-08-13 22:53:29 +1000 |
| commit | c737cde9472741337be0c0a66e8e99695c6a9b14 (patch) | |
| tree | 1d2d5a3d9b0580cc2d0a8abacbec98a55fb3d791 /docs/library/ssl.rst | |
| parent | 218606351c6f9688a3f90dad791bcb2109adcf1b (diff) | |
| download | micropython-c737cde9472741337be0c0a66e8e99695c6a9b14.tar.gz micropython-c737cde9472741337be0c0a66e8e99695c6a9b14.zip | |
docs: Replace ufoo with foo in all docs.
Anywhere a module is mentioned, use its "non-u" name for consistency.
The "import module" vs "import umodule" is something of a FAQ, and this
commit intends to help clear that up. As a first approximation MicroPython
is Python, and so imports should work the same as Python and use the same
name, to a first approximation. The u-version of a module is a detail that
can be learned later on, when the user wants to understand more and have
finer control over importing.
Existing Python code should just work, as much as it is possible to do that
within the constraints of embedded systems, and the MicroPython
documentation should match the idiomatic way to write Python code.
With universal weak links for modules (via MICROPY_MODULE_WEAK_LINKS) users
can consistently use "import foo" across all ports (with the exception of
the minimal ports). And the ability to override/extend via "foo.py"
continues to work well.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Diffstat (limited to 'docs/library/ssl.rst')
| -rw-r--r-- | docs/library/ssl.rst | 20 |
1 files changed, 10 insertions, 10 deletions
diff --git a/docs/library/ssl.rst b/docs/library/ssl.rst index 77d278d41d..4726daa59b 100644 --- a/docs/library/ssl.rst +++ b/docs/library/ssl.rst @@ -1,7 +1,7 @@ -:mod:`ussl` -- SSL/TLS module -============================= +:mod:`ssl` -- SSL/TLS module +============================ -.. module:: ussl +.. module:: ssl :synopsis: TLS/SSL wrapper for socket objects |see_cpython_module| :mod:`python:ssl`. @@ -13,14 +13,14 @@ facilities for network sockets, both client-side and server-side. Functions --------- -.. function:: ussl.wrap_socket(sock, server_side=False, keyfile=None, certfile=None, cert_reqs=CERT_NONE, ca_certs=None, do_handshake=True) +.. function:: ssl.wrap_socket(sock, server_side=False, keyfile=None, certfile=None, cert_reqs=CERT_NONE, ca_certs=None, do_handshake=True) - Takes a `stream` *sock* (usually usocket.socket instance of ``SOCK_STREAM`` type), + Takes a `stream` *sock* (usually socket.socket instance of ``SOCK_STREAM`` type), and returns an instance of ssl.SSLSocket, which wraps the underlying stream in an SSL context. Returned object has the usual `stream` interface methods like ``read()``, ``write()``, etc. A server-side SSL socket should be created from a normal socket returned from - :meth:`~usocket.socket.accept()` on a non-SSL listening server socket. + :meth:`~socket.socket.accept()` on a non-SSL listening server socket. - *do_handshake* determines whether the handshake is done as part of the ``wrap_socket`` or whether it is deferred to be done as part of the initial reads or writes @@ -36,7 +36,7 @@ Functions .. warning:: - Some implementations of ``ussl`` module do NOT validate server certificates, + Some implementations of ``ssl`` module do NOT validate server certificates, which makes an SSL connection established prone to man-in-the-middle attacks. CPython's ``wrap_socket`` returns an ``SSLSocket`` object which has methods typical @@ -54,8 +54,8 @@ Exceptions Constants --------- -.. data:: ussl.CERT_NONE - ussl.CERT_OPTIONAL - ussl.CERT_REQUIRED +.. data:: ssl.CERT_NONE + ssl.CERT_OPTIONAL + ssl.CERT_REQUIRED Supported values for *cert_reqs* parameter. |