On 2021-06-28 07:03, Thomas Grainger wrote:
but in this case the object is security sensitive, and security should be much more rigorous in ensuring correctness.
It looks like there's a consensus being reached, should I create a bpo?
If we're going to make backwards-incompatible changes to SSLContext, might it be a good idea to make a cleaner, more Pythonic API while we're at it so that people are discouraged from doing attribute-setting at all? Why not have the class accept only valid options at creation time and raise an error if any unexpected arguments are passed? Is there even any reason to allow changing the SSLContext parameters after creation, or could we just freeze them on instance creation and make people create a separate context if they want a different configuration? I think any of these would be better than the current setup that expects people to adjust the options by manually setting attributes one by one after instance creation.