Per discussion within Issue10050, URLopener ought to support the context manager protocol. That allows more idiomatic usage and doesn't require calls to contextlib.closing for use with the 'with' statement.

If agreed, I'll create a patch.

+1.

In looking at this again, I may have spoken too soon. It seems that addinfobase & HTTPResponse already handle this. As this is what's returned by the opener, then what I was shooting for should already be handled.

well, urlopen does return an file like object for socket connection which closes itself when it goes out of scope, as you raised this bug, I think a more explicit context manager like behavior can be tried. But I am afraid that it would complex to implement with the module than it sounds.

I see some example illustrated like this:
http://stackoverflow.com/questions/1522636/should-i-call-close-after-urllib-urlopen

import contextlib

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


But it would be good to have this ticket as a feature request open.

Isn't that snippet (contextlib.closing(...)) passing the result of urllib.urlopen to closing? The urlopen call is a factory function of sorts, so there's really no context to manage on its part?  Maybe it's just a matter of making that clear?

If you can share what you've got in mind, I'd love to give it a go. The urllib stuff I've done thus far has been a great way to get my feet wet!

I forgot completely, but in Python3, Issue5418 had already added
support to addinfourl. It is now possible to write code like

import urllib.request

with urllib.request.urlopen('http://www.python.org') as req:
    res = req.read()

But yeah, unlike normal file objects, it not a strict requirement for
closing those objects as they will be closed when socket connection is
closed.

This is available only 3.x series and I think, a documentation update
should be fine and this report can be closed.

Documentation patch to outline the use of context manager protocol attached. Trying to cleanup any bugs with my name on them.

Thanks for the patch.
 
-   This function returns a file-like object with two additional methods from
+   This function returns a file-like object that supports the Context Manager 
+   protocol, with two additional methods from

The capitalization seems unneeded to me.  Also, in my opinion saying “file-like” implies support for the context manager protocol, even if not all file-likes do, and anyway not all users share my assumption.  What do you think about this wording:

    This function returns a file-like object that works as a :term:`context manager`
    and has two additional methods from the :mod:`urllib.response` module

The term role creates a link to the glossary.  (BTW the entry for context manager could be improved to give open as example; I’ll do that.)

+It is also possible to achieve the same result using a context manager
+approach. ::

I would rather use with statements everywhere, or if it makes sense to have examples both with and without with, to put the example with with first.

Yeah, updated with different wording and proper caps.  I left the piece in regarding the use without the context manager as I think that's probably the more common use case still.

New changeset 8625627969aa by Senthil Kumaran in branch '3.2':
closes Issue12365 - Add an example explaining the context manager use case of urllib.urlopen
http://hg.python.org/cpython/rev/8625627969aa

New changeset 074e12441ed6 by Senthil Kumaran in branch 'default':
default: closes Issue12365 - Add an example explaining the context manager use case of urllib.urlopen
http://hg.python.org/cpython/rev/074e12441ed6

Thanks for the patch, Jeff McNeil. I pushed the patches to 3.2 and 3.3 docs. Since it is a documentation change (an explaination rather), I did not update the NEWS.

Thanks again!