This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ygale
Recipients alexandre.vassalotti, ygale
Date 2007-10-22.08:05:50
SpamBayes Score 0.014287027
Marked as misclassified No
Message-id <>
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
  <do stuff>

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.)
Date User Action Args
2007-10-22 08:05:52ygalesetspambayes_score: 0.014287 -> 0.014287027
recipients: + ygale, alexandre.vassalotti
2007-10-22 08:05:51ygalesetspambayes_score: 0.014287 -> 0.014287
messageid: <>
2007-10-22 08:05:51ygalelinkissue1286 messages
2007-10-22 08:05:50ygalecreate