This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.smith
Recipients docs@python, eric.smith
Date 2015-06-03.13:10:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2015-06-03 13:10:46eric.smithsetrecipients: + eric.smith, docs@python
2015-06-03 13:10:46eric.smithsetmessageid: <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za>
2015-06-03 13:10:46eric.smithlinkissue24372 messages
2015-06-03 13:10:45eric.smithcreate