fix:fix response format bug

[guaguaguaxia]

[guaguaguaxia]

@MattFisher please review it, i don't know how i close last same PR 😭

[MattFisher]

I'm not a maintainer of the project or anything, just another user!

Though as I said here, I think this will fix the issue without further code changes.

The Content-Type header on the response is always set correctly (at least for the audio transcription responses), so we can deduce whether to json-decode within APIRequestor._interpret_response.

For the json and verbose_json response formats, the Content-Type is 'application/json', while for text, srt, and vtt, the Content-Type is 'text/plain; charset=utf-8'.

[guaguaguaxia]

I'm not a maintainer of the project or anything, just another user!

ok thanks

[MattFisher]

I've manually tested the change and it works for all the different audio response formats. I can't verify that it doesn't break any other endpoints though.

[guaguaguaxia]

@MattFisher I thought about it for a second,i still think we should define a enum and add a function parameter to make code more clearly

[MattFisher]

@guaguaguaxia that would make sense if the Audio module was the only code that consumed the APIRequestor class, but it's not. APIRequestor is used all through the codebase, so if we were going to add an extra parameter to its __init__ method, that would imply that all the other modules need to know about that parameter. In this case, that doesn't make sense, because the choices for that parameter are specific to the Audio transcribe function. Other callers of APIRequestor() would then expect to be able to pass response_format='text' and get back some textual representation of the response, which isn't going to work.

[guaguaguaxia]

@guaguaguaxia that would make sense if the Audio module was the only code that consumed the APIRequestor class, but it's not. APIRequestor is used all through the codebase, so if we were going to add an extra parameter to its __init__ method, that would imply that all the other modules need to know about that parameter. In this case, that doesn't make sense, because the choices for that parameter are specific to the Audio transcribe function. Other callers of APIRequestor() would then expect to be able to pass response_format='text' and get back some textual representation of the response, which isn't going to work.

you r right, i am not familiar with this project structure

[MattFisher]

Might want to roll back the whitespace changes in openai/util.py

[guaguaguaxia]

@MattFisher thanks.

@logankilpatrick @mpokrass you can see this:https://github.com/openai/openai-python/issues/243#issuecomment-1457398603

[hallacy]

Looks awesome! Thanks for writing the PR!

[dusdb1]

Now, response_format is in plain text and not defaults to json format as it says in docs, right?

[guaguaguaxia]

Now, response_format is in plain text and not defaults to json format as it says in docs, right?

No，if response_format type is json or verbose_json,it still return json,other return text