Fixed regression that tests using format still work

[sliverc]

Description

This is a fix for a regression introduced in PR #6511 which we discovered in our tests run on Django REST framework JSON:API against DRF master.

The error only occurred on tests which return no content (e.g. delete), use a renderer without charset (e.g. JSONRenderer) and using format to determine the renderer.

[browniebroke]

Looking at the PR that caused the regression, it seems to be related to trying to fix something else:

• Ensure the result of _encode_data is always Tuple[bytes, str] rather than Tuple[Union[bytes,str], str]

We used to have an early return which was returning a str instead of bytes as body, and the OP fixed it by moving it down, missing the edge case you're hitting. Basically, the code of the fix was: https://github.com/encode/django-rest-framework/pull/6511/files#diff-41414b310a542c20e4f2a1eac261e03c2344ac69ff2ee4607c22632e6b19ad30R159-R162

I'd rather we go closer to the original code, keeping this core change, and with the early return changed from ('', content_type) to (b'', content_type). That would IMO avoid the chance of more regressions before we release.

[sliverc]

@browniebroke Thanks for your feedback. I totally agree that we should have an early return as before, which avoids many checks on the way. I will adjust the PR later on today then.

[sliverc]

@browniebroke Updated. It is now as close to what it was before #6511 but ensuring that the early out is also bytes. Let me know what you think.

[browniebroke]

Noting that this bit used to be de-dented one level before #6511:

Suggested change

	# Coerce text to bytes if required.
	if isinstance(ret, str):
	ret = ret.encode(renderer.charset)
	# Coerce text to bytes if required.
	if isinstance(ret, str):
	ret = ret.encode(renderer.charset)

On the other hand, I don't see how ret.encode(renderer.charset) can work if renderer.charset is falsy (most likely None)... I'm guessing the if branch at line 187 is always True.

All in all, I'm not sure my above suggestion matters, but if someone can think of a test case where it does, I'm open to hear it.

[sliverc]

I did this as charset can be None and encode raises an exception when None is passed. As far as I understand it, when a renderer sets charset to None (e.g. JSONRenderer) it handles the encoding on its own and returns bytes. However, if the renderer faultily returns str and has charset set to None, an exception occurred before this change.

My fix indenting the str check when no charset is set, actually avoids the exception which, when thinking about it again, might make things worse as it is a misconfiguration. One could argue an assert might be better in this case. I guess though if so that should be better part of another PR and I assume it has not been an issue in the past, so let's keep it as it was.

I will remove the indent again then.

[browniebroke]

That looks good from my perspective. I'll leave the final word to @auvipy who reviewed #6511 to confirm my assesment of the revert.