ENH Add response.text to pyodide.http.FetchResponse

[hoodmane]

We've received feedback from users that use other requests APIs that they expect the method to be called response.text instead of response.string. Indeed both the Fetch response API and the Python requests library use this convention:

https://developer.mozilla.org/en-US/docs/Web/API/Response/text https://requests.readthedocs.io/en/latest/api/#requests.Response.text

This adds response.text to FetchResponse. It is a synonym for response.string.

This also marks response.string as deprecated but does not schedule it for removal.

cc @pelson who suggested this change.

• Add a CHANGELOG entry
• Add new / update outdated documentation

[ryanking13]

Thanks! Please update the changelog.

We could also deprecate response.string but I don't see any immediate need to do so.

Yes, I think we can just keep it for backward compatibility.

[rth]

We could also deprecate response.string but I don't see any immediate need to do so.

Can we at least mention in the docstring which one should be used, and mention that the other one is deprecated in the docstring? Having two methods that do exactly the same thing is not very pythonic. But yeah I agree that there is no need to actually raise a deprecation warning.

[hoodmane]

Right again there are three different possible things:

1. we tell people not to use it
2. we tell people not to use it and warn if they do
3. we tell people not to use it and warn if they do and have a schedule to remove it

I think I usually think "deprecated" means either 2 or 3, so far we've been using it for 3. CPython has a new "soft deprecation" which is 1. But we should make sure to make it clear what specifically we mean...

[ryanking13]

1. we tell people not to use it

I think option 1 with mentioning not to use it in the docstring is okay for this case, as the extra maintenance burden is negligible.