[Python-Dev] Adding test.support.safe_rmpath()

[Tim Golden]

On 14/02/2019 15:24, Giampaolo Rodola' wrote:
> 
> 
> On Thu, Feb 14, 2019 at 4:03 PM Tim Golden <mail at timgolden.me.uk 
> <mailto:mail at timgolden.me.uk>> wrote:
> 
>     On 14/02/2019 14:56, Giampaolo Rodola' wrote:
>      >
>      >
>      > On Thu, Feb 14, 2019 at 3:25 PM Eric Snow
>     <ericsnowcurrently at gmail.com <mailto:ericsnowcurrently at gmail.com>
>      > <mailto:ericsnowcurrently at gmail.com
>     <mailto:ericsnowcurrently at gmail.com>>> wrote:
>      >
>      >     On Thu, Feb 14, 2019, 02:47 Ronald Oussoren via Python-Dev
>      >     <python-dev at python.org <mailto:python-dev at python.org>
>     <mailto:python-dev at python.org <mailto:python-dev at python.org>> wrote:
>      >
>      >
>      >         I usually use shutil.rmtree for tests that need to create
>      >         temporary files, and create a temporary directory for those
>      >         files (that is, use tempfile.mkdtemp in setUp() and use
>      >         shutil.rmtree in tearDown()). That way I don’t have to adjust
>      >         house-keeping code when I make changes to test code.
>      >
>      >
>      >     Same here.
>      >
>      >     -eric
>      >
>      >
>      > What I generally do is avoid relying on tempfile.mkdtemp() and
>     always
>      > use TESTFN instead. I think it's cleaner as a pradigm because
>     it's an
>      > incentive to not pollute the single unit tests with 
>     `self.addCleanup()`
>      > instructions (the whole cleanup logic is always supposed to occur in
>      > setUp/tearDown):
> 
>     Must chime in here because I've been pushing (variously months & years
>     ago) to move *away* from TESTFN because it generates numerous
>     intermittent errors on my Windows setup. I've had several goes at
>     starting to do that but a combination of my own lack of time plus some
>     people's reluctance to go that route altogether has stalled the thing.
> 
>     I'm not sure I understand the difference in cleanup/teardown terms
>     between using tempfile and using TESTFN. The objections I've seen from
>     people (apart, obviously, from test churn) are to do with building up
>     testing temp artefacts on a possibly low-sized disk.
> 
>     TJG
> 
> 
> I suppose you mean the intermittent failures are usually due to "file is 
> already in use by another process" correct? test.support's unlink(), 

Occasionally (and those are usually down to a poorly-handled cleanup).

More commonly it's due to residual share-delete handles on those files, 
probably from indexing & virus checkers or TortoiseXXX cache handlers. 
Obviously I can (and to some extent do) try to mitigate those issues.

In short: reusing the same filepath over and over for tests which are 
run in quick succession doesn't seem like a good idea usually. That's 
commonly what TESTFN-based tests do (some do; some don't).

I'm 100% with you on strict clean-up, not leaving testing turds behind, 
not over-complicating simple tests with lost of framework. All that. But 
-- however it's done -- I'd prefer to move away from the test-global 
TESTFN approach.

I'm not at my dev box atm so can't pick out examples but I definitely 
have some :) I have no issue with your proposal here: better and simpler 
cleanup is A Good Thing. But it won't solve the problem of re-using the 
same test filepath again and again.

TJG