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