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.
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
Python-ideas mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Message archived at https://email@example.com/message/K5ZBPHYL4UUFY7T3VDXZJIEX6WQJCBXG/
Code of Conduct: http://python.org/psf/codeofconduct/