How different is this from Pyodide's pyfetch?
https://pyodide.org/en/stable/usage/api/python-api/http.html

@hoodmane the requirements were discussed in here and the issue describes the final goal.

The idea was to provide a cross interpreter easy-peasy way to simply fetch data and with the following goals:

• it should work consistently in both Pyodide and MicroPython without asking MicroPython to implement the whole Pyodide API
• it should be the easiest possible way for users that don't necessarily expect to handle Response results, meaning it requires a single await fetch(url).text() instead of double await ... this has been recently proven to be desired most of the cases and if users need to fine-tune or better handle in a more robust way all possible cases and quirks, they can just use the native js.fetch API or use pyfetch from Pyodide or do whatever they need to do

I hope this reasons well but happy to be corrected from @ntoll or maybe he'd like to add more to it 👋

edit btw, I do think we should mention that for broader use cases the pyodide.http.pyfetch API should be considered, I hope Nicholas agrees here. I don't think we have any equivalent in MicroPython though so that would be Pyodide specific.

edit never mind, I've already implemented and tested this, we should be good now

@ntoll one thing maybe we can also do is to check response.ok for all methods and provide a nice error in case stuff didn't work as expected ... this is specially handy in case the request was a 404 or 500 and we don't want the rest of the code to eventually parse or evaluate those HTML pages (think a .text() that actually failed).

I don't have a strong opinion about this but it was the only thing users were slightly worried about in my fetch module case.