The standard idiom for opening a file is now with open...
So I think it should be a goal that this should work with
any built-in file-like object that needs to be closed,
without having to explicitly wrap it in closing().
It certainly should work for fileinput and StringIO - since
these really are files, in some sense.

Do you have a use-case for this? In Py3k, I don't think adding support
for the 'with' statement to StringIO makes any sense, since the close()
method does nothing.

These objects are supposed to be drop-in replacements
for file handles. Except in legacy code, the way you
use a file handle is:

with function_to_create_fh as fh:
  <do stuff>

If these objects do not support the with protocol,
the only way to use them is to refactor this code.
That may not even be possible, e.g., if it is in
a library, or it may not be desirable to refactor.

Even if you can refactor it, I don't think you
can call these objects file-like objects if
you can't use them like a file.

Note that in legacy code, you used to write:

fh = function_to_get_fh
try:
  <do stuff>
finally:
  fh.close()

If function_to_get_fh happens to return some other
file-like object and not an actual file,
this still works fine without any refactoring.

You wrote:
> In Py3k, I don't think adding support
> for the 'with' statement to StringIO makes
> any sense, since the close()
> method does nothing.

So do you propse removing the close() method
altogether? Of course the answer is "no",
because then you could not use the object like
a file. The same is true for the with protocol.

(I now retract the words "that needs to be closed"
from my original comment. All file-like objects
should support the with protocol, regardles of
whether their close() method actually does anything.)

Makes sense to me.

Let's not get overexcited. I agree that it makes sense for fileinput,
but I disagree about *StringIO; its close() isn't needed to free
resources (since it doesn't use up a scarce resource like a file
descriptor).

Can you whip up a patch for fileinput?  Please include unit tests and
documentation.

I was actually bitten badly by this issue with
StringIO. I added fileinput only as an afterthought.

In an xml.sax app, I needed seek() support for a
codec-wrapped file handle, so I over-wrapped it with
StringIO. The result was that I had to refactor code all over
the place to handle StringIO as a special case. What a
mess!

Why is this getting over-excited? It's a very
lightweight change. You can't beat the cost/benefit ratio.

2007/10/25, Yitz Gale <report@bugs.python.org>:
> I was actually bitten badly by this issue with
> StringIO. I added fileinput only as an afterthought.
>
> In an xml.sax app, I needed seek() support for a
> codec-wrapped file handle, so I over-wrapped it with
> StringIO. The result was that I had to refactor code all over
> the place to handle StringIO as a special case. What a
> mess!

I don't understand. What did your code look like after the refactoring?

I find that typically a useful idiom is to have one piece of code
handle opening/closing of streams and let the rest of the code just
deal with streams without ever closing them. E.g.

f = open(filename)
try:
  process(f)
finally:
  f.close()

or, if you want:

with open(filename) as f:
  process(f)

As I don't understand how you are working the StringIO() call into
this I'm still not sure what the issue is.

> Why is this getting over-excited? It's a very
> lightweight change. You can't beat the cost/benefit ratio.

Until you submit a patch it's more work for me. :-)

FYI, StringIO and BytesIO, in Python 3K, already support the context
management protocol.

Attached patch implements context management protocol for StringIO.

Attached is a patch against trunk r76325 which implements context
manager support for fileinput/FileInput, with tests and doc change.