BUG: file leak in read_excel

[jbrockmendel]

I think this
closes #30031
closes #29514
we'll probably want to wait a few days to make it official.

To make the new test decorator useful in the CI we'll need to add psutil to the environment (unless someone knows of a stdlib way of doing the same check?)

One more note, the check in check_no_file_leaks depends on __del__ having been called, which in turn depends on the gc. I'm not sure, but that might induce another layer of flakiness. If so, I think that can be fixed by calling gc.collect() before doing the flist == flist2 check

[alimcmaster1]

LGTM - if this works! thanks for the fix!

[jreback]

great. maybe keep rebasing a few times this to see if it fails.

[jbrockmendel]

maybe keep rebasing a few times this to see if it fails.

Seems like a more effective way of checking this against many runs would be to merge and see if the py36 failures go away?

[jreback]

maybe keep rebasing a few times this to see if it fails.

Seems like a more effective way of checking this against many runs would be to merge and see if the py36 failures go away?

sure

[jonashaag]

@jbrockmendel xref #47656: Does this miss a gc.collect() before the leak check? Some leaks will go away with a GC run. In #47656 there are a bunch of boundmethod objects that form a cycle with their originator class (SAS7BDATReader).

[jbrockmendel]

That's plausible, but I'll need a lot more caffeine to say more than that. An extra better-safe-than-sorry gc.collect call wouldn't be the end of the world.