New submission from Eric V. Smith:
The documentation for ssl.wrap_socket()'s ssl_version parameter says
"ssl_version={see docs}". But as far as I can tell, there's no reason not to
document it as PROTOCOL_SSLv23, since that's what it actually is in the code.
My use case is that I'm producing a utility function for an RFC-5804 Manage
Sieve client, which implements starttls(). I want to expose most of
wrap_sockets()'s parameters, and pass them in to ssl.wrap_socket() itself. In
order to do so, I need to specify the default values to match wrap_socket().
But ssl_version's default isn't documented.
Is the reason to allow us to change the default in a bug fix release? If that's
the case, I suggest creating a sentinel value, like ssl.DEFAULT_PROTOCOL, and
have that be the documented default. Then I could declare my parameter as
defaulting to ssl.DEFAULT_PROTOCOL, pass it in to ssl.wrap_socket(), and have
it use the "current" default.
If that's a desirable solution, I'll happily write a patch. If so, it would
just apply to 3.6, but if we just want to document the actual value of
ssl_version, then it would apply to the versions I've selected.
----------
assignee: docs@python
components: Documentation, Library (Lib)
messages: 244742
nosy: docs@python, eric.smith
priority: low
severity: normal
status: open
title: Documentation for ssl.wrap_socket's ssl_version parameter is odd
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24372>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
