On Fri, Jun 25, 2021 at 12:17 PM Christian Heimes <christian@python.org> wrote:
On 25/06/2021 20.17, Guido van Rossum wrote:
> On Fri, Jun 25, 2021 at 8:22 AM Bluenix <bluenixdev@gmail.com
> <mailto:bluenixdev@gmail.com>> wrote:
>     I am not fully aware of how ssl.SSLContext is used, but adding
>     __slots__ would prevent this. You would see an error similar to:
>     AttributeError: 'MyClass' object has no attribute 'my_attribute'
> That's a reasonable solution, except that it's not backwards compatible.
> It's possible that there is code out there that for some reason adds
> private attributes to an SSLContext instance, and using __slots__ would
> break such usage. (They could perhaps fix their code by using a dummy
> subclass, but that could well become a non-trivial change to their code,
> depending on where they get their SSLContext instances.)
> So unless there's evidence that nobody does that, we're stuck with the
> status quo. I'm adding Christian Heimes to the thread in case he has a
> hunch either way.

I agree, it is a backwards incompatible change. Also __slots__ won't
work. The class has class attributes that can be modified in instances.

Oh, I see. There are two class attributes, sslsocket_class and sslobject_class, and their docs say they can be overridden per instance. Could we perhaps create a custom descriptor that allows both per-instance and per-class assignment and lookup?
You cannot have attributes that are both class and instance attributes
with __slots__. We'd have to overwrite __setattr__() and block unknown
attributes of exact instances of ssl.SSLContext.

Well, if we don't think it's supported behavior to subclass SSLContext, perhaps we could do that. The bug in the OP's code (misspelling minimum_version in assignment) is pretty hard to find.

--Guido van Rossum (python.org/~guido)