I noticed that it would be nice to have a temporary directory contextmanager while trying to fix a broken unittest.  The attached patchprovides a pretty minimal implementation.  There appears to be lots ofunit tests that could use such a thing (just search for "rmtree").I'm not sure if TemporaryDirectory is the best name.  Also, perhaps itshould have a __del__ method although that's tricky business.

A __del__ method is definitely desirable (tempfile._TemporaryFileWrappergives an example of how to cache the relevant globals on the classobject to avoid attempting calls to None during interpreter shutdown).The new examples are good, but may give the misleading impression thatTemporaryFile can't be used as a context manager (it can, and the filewill be closed at the end of the with statement). A second file exampleshowing it being used as a context manager would probably be helpful.There is also at least one existing contextlib based temp_dir contextmanagers that could be replaced given the addition of this (i.e. intest_cmd_line_script.py, "test_dir" could be changed to a class thatinherits from tempfile.TemporaryDirectory and overrides __enter__ toinvoke realname() on the directory name).

New version of the patch.  Added a __del__ method that hopefully worksreliably.  Added NEWS and an example of TemporaryFile as a contextmanager.  I did not change more tests to use TemporaryDirectory since Iunderstand hit-and-run modernization of code is generally discouraged. That said, I think there are some tests that could have theirreliability improved by using TemporaryDirectory (I started on thispatch when I saw some build bot failures).  I'll look into that later.

If you look at the code for os.path.isdir, it uses other globals such asos.stat, so you might want to reinject them in your class as well...

Argh, it's like pulling a sweater thread.  The stat.S_ISDIR functionuses the S_IFDIR global so I would have write my own.  This does notlook like good maintainable code, IMO.Maybe there should be a special flag modules can set to make them getcleared later in the interpreter cleanup procedure.  Modules could setit if they don't create reference cycles themselves and don't holdreferences to user objects.

> Maybe there should be a special flag modules can set to make them get> cleared later in the interpreter cleanup procedure.  Modules could set> it if they don't create reference cycles themselves and don't hold> references to user objects.Or, perhaps we could remove the assignment to None and use afinalization scheme based on the garbage collector instead.See#812369 (no patch for the above idea unfortunately).

Unassigning for the moment - I'm still interested in the idea, but thereferencing-globals-at-shutdown problem means it isn't going to be thestraightforward review-and-commit that I original thought this patch wasgoing to be.I'll still try to get to it before the next 3.1 alpha in a couple ofweeks, but I don't want to stop anyone else from looking at it in themeantime.

Building a collection of issues I want to take a look at for 2.7

Missed the boat for 2.7 I'm afraid. Definitely one to take another look at for 3.2 though.

Ping... soon it's too late for 3.2 too :)

Personally I would like to have a unique tempfile.mkdtemp which can be used as both a function and a context manager, as it happens for open() and others.Not sure how to do that though, unless tempfile.mkdtemp gets turned into a class.There would be objections against doing that?

Committed (with enhanced tests and a few fixes) inr85818And credit where it's due to test___all__ for picking up a typo in my adjustment to tempfile.__all__ :)I created issue#10188 to track the shutdown problem. I'm considering taking out the code that attempts to allow the __del__ method to work at shutdown though, since it isn't actually achieving anything (I wanted a record of it in the main repository, which is why I kept it for the initial checkin).

Nick, could you comment about my last proposal?

Merging the interfaces for mkdtemp and TemporaryDirectory isn't going to happen.mkstemp/mkdtemp are for when the user wants to control the lifecycle of the filesystem entries themselves. (Note that context management on a regular file-like object only closes the file, it doesn't delete it from the filesystem). They're also intended as relatively thin wrappers around the corresponding C standard library functionality.The other objects in tempfile (TemporaryFile, TemporaryDirectory, etc) are for when the user wants the lifecycle of the Python object to correspond with the lifecycle of the underlying filesystem element.That said, TD itself can be used to create the temporary directory without having to use it as a context manager (the underlying directory is created in __init__, not __enter__).