should I call close() after urllib.urlopen()?

Question

I'm new to Python and reading someone else's code:

should urllib.urlopen() be followed by urllib.close()? Otherwise, one would leak connections, correct?

Answer 1

The close method must be called on the result of urllib.urlopen, not on the urllib module itself as you're thinking about (as you mention urllib.close -- which doesn't exist).

The best approach: instead of x = urllib.urlopen(u) etc, use:

import contextlib

with contextlib.closing(urllib.urlopen(u)) as x:
   ...use x at will here...

The with statement, and the closing context manager, will ensure proper closure even in presence of exceptions.

Answer 2

Like @Peter says, out-of-scope opened URLs will become eligible for garbage collection.

However, also note that urllib.py defines:

 def __del__(self):
        self.close()

This means that when the reference count for that instance reaches zero, its __del__ method will be called, and thus its close method will be called as well. The most "normal" way for the reference count to reach zero is to simply let the instance go out of scope, but there's nothing strictly stopping you from an explicit del x early (however it doesn’t directly call __del__ but just decrements the reference count by one).

It's certainly good style to explicitly close your resources -- especially when your application runs the risk of using too much of said resources -- but Python will automatically clean up for you if you don't do anything funny like maintaining (circular?) references to instances that you don't need any more.

Answer 3

Strictly speaking, this is true. But in practice, once (if) urllib goes out of scope, the connection will be closed by the automatic garbage collector.

Answer 4

You basically do need to explicitly close your connection when using IronPython. The automatic closing on going out of scope relies on the garbage collection. I ran into a situation where the garbage collection did not run for so long that Windows ran out of sockets. I was polling a webserver at high frequency (i.e. as high as IronPython and the connection would allow, ~7Hz). I could see the "established connections" (i.e. sockets in use) go up and up on PerfMon. The solution was to call gc.collect() after every call to urlopen.