Related to this older Issue, we started to encounter this problem through our robocorp libraries (where injection gets done -- so at CLI level, not library) and now I observe it even in our CI during the test runs. (while I couldn't reproduce locally on the same system and Python version)
- Question is, did something change in the ssl.py so that this started to appear with the later Py3.10.x versions?
- And why is the super class invoked like this:
_original_super_SSLContext = super(_original_SSLContext, _original_SSLContext)? Even in the standard ssl module I see the same pattern when calling the verify_mode method. By looking at the docs we have the following:
super(type, type2) -> bound super object; requires issubclass(type2, type)
@verify_mode.setter
def verify_mode(self, value):
super(SSLContext, SSLContext).verify_mode.__set__(self, value)
- Don't we have a bug here with this code (_api.py)?
@verify_flags.setter
def verify_flags(self, value: ssl.VerifyFlags) -> None:
_original_super_SSLContext.verify_flags.__set__( # type: ignore[attr-defined]
self._ctx, value
).verify_flags available with PyPI.
Related to this older Issue, we started to encounter this problem through our robocorp libraries (where injection gets done -- so at CLI level, not library) and now I observe it even in our CI during the test runs. (while I couldn't reproduce locally on the same system and Python version)
_original_super_SSLContext = super(_original_SSLContext, _original_SSLContext)? Even in the standardsslmodule I see the same pattern when calling theverify_modemethod. By looking at the docs we have the following:.verify_flagsavailable with PyPI.