On Sat, Jul 28, 2018 at 10:20 AM, Tim Golden <m...@timgolden.me.uk> wrote: > > Here's the thing. The TESTFN approach creates a directory per process > test_python_<pid> and some variant of @test_<pid>_tmp inside that directory.
I filed an issue some years back about this (still open): https://bugs.python.org/issue15305 The pid is unnecessarily being used twice. Once the directory is created for the process, there shouldn't be a need to disambiguate within the directory further. > But the same filename in the same directory is used for every test in that > process. Now, leaving aside the particular mechanism by which Windows > processes might be holding locks which prevent removal or re-addition, that > already seems like an odd choice. > > I think that was my starting point: rather than develop increasingly > involved and still somewhat brittle mechanisms, why not do what you'd > naturally do with a new test and use tempfile? I was expecting someone to > come forward to highlight some particular reason why the TESTFN approach is > superior, but apart from a reference to the possibly cost of creating a new > temporary file per test, no-one really has. I think there is value in having the files used during test runs in a known location. How about a middle ground where, once the process-specific directory is created in a known location, unique files are created within that directory (e.g. using a random suffix, or a perhaps a suffix that is a function of the test name / test id)? This would address both the issue you're experiencing, and, if the directory is deleted at the end of the test run, it would address the issue Jeremy mentions of growing leftover files. There could also be a check at the end of each test run making sure that the directory is empty (to check for tests that aren't cleaning up after themselves). --Chris _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
