Andreas Maier

@tadhgpearson: Your example shows the current shortcoming: There is only one piece of information for each HTTP status code. Many HTTP status codes above 400 can have multiple reasons, each....

@jharmn This issue is marked with the "OpenAPI.Next Proposal" label. Does this mean it is being discussed for OpenAPI 3.1? If so, where does it stand?

There is also issue #2063 that seems to describe the same error.

I also get this with the built-in `Exception.args` and believe it is the same error: ``` class HTTPError(Exception): def __init__(self, status, reason): super(HTTPError, self).__init__(status, reason) @property def status(self): return self.args[0]...

I did some more investigation and found that these exceptions are actually handled and just printed in a way (with traceback) that makes one think they had not been handled....

The full log of the safety run with --debug on Python 3.6 with minimum package levels: [safety-2.2.0-issue.txt](https://github.com/pyupio/safety/files/13908494/safety-2.2.0-issue.txt)

@yeisonvargasf It turns out that the `setup.cfg` file already had the `pyton_requires` attribute, but in the wrong section. I have created PR #485 to fix that. Please review and merge.

We also had this issue with the pinning of "packaging", and tested safety 2.3.4 and 2.4.0b1 with packaging 22.0, 23.0 and 23.1 (on Python 3.9) and it all worked fine....

I have this warning too, but in my case it was caused by the use of `noga: 501` which apparently works for flake8 but causes the warning for ruff. We...

I would like to put my 2 cents in for Python 3.13 support. We are trying to test our own projects on the 3.13 beta and that fails when installing...