@guyskk

the origin code rv, status_or_headers, headers = rv + (None,) * (3 - len(rv)) is better, shorter and cleaner.

I respectfully disagree. I think using status_or_headers makes the code very hard to follow. At any point it may hold different types depending on the input, and It is also used as a sort of flag throughout the function to infer what was passed in from the view function.

Reading the function, I felt it was unnecessarily convoluted and it was difficult to follow all of the possible paths in the code.

IMHO my refactoring turns the function into a simple series of if - elif - else clauses. The logic is now far clearer.

the origin rv tuple

response,
response, status
response, headers
response, status,  headers

after append None

response, None,    None
response, status,  None
response, headers, None
response, status,  headers

so the 3 items is
response, status_or_headers,headers

@guyskk Yes, I understand the idea in rv, status_or_headers, headers = rv + (None,) * (3 - len(rv)).

I just think the same thing can be achieved with a little more code and far better readability. As demonstrated in the PR.

IMHO this function could be implemented simply with a series of elifs, so I don't see why not :)

Your implement of _make_response_from_tuple is too verbose, you need not split it into some functions, it just a little bit of code and you make it complicated.

What's more, you should not change code and tests in the same commit, can your refactor pass the origin tests?

The 2th item can be string(status) or int(statuc_code), I wonder you refactor changed this behavior.

What's more, you should not change code and tests in the same commit

Why? By doing so you have working code with passing tests in each commit.

this is a refactor other than new feature，so the behavior shouldn't change，and should pass the origin tests.

@guyskk I agree, I might have refactored into too many sub-functions.

Other than that, IMHO the refactoring is good because it gives the function a structure of simple if - elif statements, instead of the weird structure it had before.

The 'rules' governing the behavior of the function are now visible to the eye, as opposed to the way the original is structured.

However as I said, I think you are right that I refactored into too many function levels.

@ThiefMaster I am updating the PR to split into less sub-functions.

Thanks for looking into this. I agree that it was hard to follow. However, this introduced a bug where None was accepted as a response in a tuple, and the response in the tuple couldn't be a WSGI callable (although that's probably beyond rare).

I expanded on your idea by breaking out the tuple unpacking, adding more error messages, improving the documentation, and adding more tests. See #2256.