Supports both string, int, and HTTPStatus

[luolingchun]

Why did you use a custom library of strings instead of the official HTTPStatus lib built-in in Python everywhere?
flask_openapi3/http.py vs from http import HTTPStatus

There's inconsistencies vs HTTP Status as a string and HTTP Status as an int.
There's also from http import HTTPMethod for methods.

@CostcoFanboy We are here to discuss this issue.

Why did you use a custom library of strings instead of the official HTTPStatus lib built-in in Python everywhere?
flask_openapi3/http.py vs from http import HTTPStatus

At the beginning of the project, it was completely based on the OpenAPI Specification, so only the string was considered.
However, I am open to both int and HTTPStatus, and we can support both.

There's also from http import HTTPMethod for methods.

HTTPMethod was not supported until Python 3.11.

[CostcoFanboy]

I see. I do not see the battle of string vs int as intrinsically important one but what I consider important is using HTTPStatus as that's built-in and RFC-compliant. And it uses ints. So we can just cast to string every time the library's methods need a string. It would be one "less thing" to maintain in case they change the definitions in a future Python release. This way we get the value, the phrase and a description for free. So I strongly believe it should be implemented.

That's a very good point on the HTTPMethod. It was selfish of me to not check when that was implemented. Apologies. We would need to invalidate way too many Python versions because of a couple of strings. That one is not worth it in my opinion.

What do you think?

[luolingchun]

I got it!

HTTPStatus and int are equivalent, so we can use responses={"200": Message}, responses={200: Message} or responses={HTTPStatus.OK: Message} when this issue is solved.

What I mean is that we cannot give up supporting string just because of HTTPStatus.

[CostcoFanboy]

What I mean is that we cannot give up supporting string just because of HTTPStatus.

I see, my apologies it seems there are miscommunications between us.
This library you started therefore your vision matters the most. I'd give up support of strings personally as it's cleaner in the end. Also the existence of an HTTP status cannot differ from an integer, therefore it should be only in integers. Not only because of HTTPStatus and the way the Python language is moving.

Reading ints is also faster than a string alone, so "Small" performance improvement at no cost.