In the spirit of files becoming context managers in 2.5, the attached patch defines __enter__ and __exit__ methods for tempfile.NamedTemporaryFile. BTW, I was not able to add a "patch" keyword which seems appropriate here.
Thanks for the patch! It even has a unit test, very good. :) The __future__ statement isn't necessary for Python 2.6. The with statement is always available.
I've changed the issue type from rfe to behaviour. NamedTemporaryFile actually provides __enter__ and __exit__ methods in 2.5, they just don't work (it tries to use the methods from the underlying file object directly which turns out to be a doomed exercise for a couple of different reasons). Fixed on the trunk in r60695. Leaving issue as pending until the NamedTemporaryFile fix is backported to 2.5 (or we decide not to backport it). P.S. Alexander's patch worked as written, but in figuring out *why* it worked I ended up moving things around a bit (main change was to only override __exit__ when it was actually necessary to do so) and adding some more test cases (e.g. to also cover 2.6's new SpooledTemporaryFile).
Nick's comment made me think why NamedTemporaryFile can't simply subclass file and get properly working context manager's methods for free. It turned out that although file is subclassable, in its present form, it does not allow NamedTemporaryFile implementation for the following reasons: 1. os.fdopen cannot create a subclass of file. 2. file.__exit__ does not call subclass' close method. The attached patch fixes both issues and reimplements NamedTemporaryFile. I understand that adding new functionality to file objects should be brought up on python-dev, but I would like to hear comments from the "nosy list" first. The patch is proof-of-concept quality at the moment and may not work non-posix platforms.
The wrapper approach has the virtue of providing easy access to the underlying file object and its methods. That actually gets a bit more difficult when you switch to a subclassing approach (you need to either explicitly qualify the methods or play around with super()). The wrapper approach also has the virtue of being a valid candidate for backport to 2.5.2, while that is most definitely *not* the case for making file fully subclassable. If you would like to pursue that idea further, I suggest opening a separate issue for it.
Backported to 2.5 in r60728 P.S. To elaborate a bit more on why converting NamedTemporaryFile to subclass file would be a much bigger deal than it is to just fix its __enter__ and __exit__ methods: - converts from old-style to new-style class - imposes the constraints of a C base class on any subclasses - file attribute is currently part of the public API - need to retain wrapper approach in tempfile anyway for related type SpooledTemporaryFile in 2.6 (as that may contain a real file or a string IO object at different points in its lifecycle) - no compelling use case for the change (the wrapper approach works, what real advantage do we gain from subclassing file instead?) - wrapper approach is much easier to reconcile with Python 3.0's io module
