When looking at the implementation of the Response.close() method [1], we can see it deviates from the original implementation [2] by adding a gc.collect() just before returning.

To make the GC actually free heap memory, you probably also added del self.socket and del self._cached beforehand. However, these will also remove the instance attributes completely, so this will lead to other problems by methods still trying to use them even when the socket connection has been shut down already. Reproducing this condition should be easy and is obvious to spot - just imagine invoking the Response.close() method twice where even checking for if self.socket would then fail badly like

AttributeError: 'Response' object has no attribute 'socket'

That would even not be unlikely as I see Response.__exit__() will also invoke self.close() - no matter whether it has been called before.

So, I am humbly asking if just setting these two instance attributes to None by self.socket = None and self._cached = None will not be sufficient to make the GC pick up the orphaned Python objects and free them?

If nothing speaks against this, I would like to vote to change this in order to make the library more robust - even in error conditions and unforeseen bogus usage.

[1] https://github.com/adafruit/Adafruit_CircuitPython_Requests/blob/v1.1.0/adafruit_requests.py#L94-L100
[2] https://github.com/micropython/micropython-lib/blob/829f53dc/urequests/urequests.py#L10-L14

Hi @amotl! Please make a pull request with your suggested changes. This code is relatively new and evolving so we're happy to merge them in. Let us know if you need help getting it going.

Dear Scott,

thanks for your quick answer.

We are about to switch over to Adafruit_CircuitPython_Requests within our Terkin Datalogger.

We have not been able to make this switchover yet. In the meanwhile, we fixed the uurequests module of Pycopy to suite our needs, see daq-tools/pycopy-lib@89cad7d9 as a reference for that.

As soon as we might be going towards using Adafruit_CircuitPython_Requests, we will be happy to submit an appropriate pull request.

With kind regards,
Andreas.

P.S.: The background of our current work is that we are conceiving a powerful CPython- and pytest-based test harness for our Terkin Datalogger, which might also spark your interest [1,2].

Let us know if you need help getting it going.

From investigating the source code of this module, I definitively have a few remarks about compatibility with CPython and Genuine MicroPython. However, I will open another issue about that in order not to hijack this one.

[1] https://github.com/hiveeyes/terkin-datalogger/tree/master/test
[2] https://community.hiveeyes.org/t/developing-terkin-for-micropython/233/25

Hi there,

thanks for putting more efforts into this implementation. I can now see that after f32426d and e372574 on behalf of #31 by @tannewt,

is only made at the end of the close() method and nowhere else. That will probably have resolved the condition I was describing here, so I feel it will be safe to close this issue.

Keep up the spirit and with kind regards,
Andreas.