Confirmed! It works for me (at least locally).

Could you explain a bit how you came up with this specific solution? I understand that the process was keeping the tmpdir alive but still unsure of why the__del__ wasn't called properly (or didn't let the tmpdir be gc'ed). I had some trouble debugging this issue myself, so any tips/pointers are appreciated. Thanks!

I'm not actually 100% sure of what's happening (especially wrt. the precise timing where__del__ gets called), but I believe the problem is that even when the Popen object gets gc'ed, that doesn't actually kill the underlying process (this can be checked e.g. on linux withpython -c 'from subprocess import Popen; Popen("sleep 1; echo foo", shell=True)': "foo" is printed after python exited (so certainly the Popen object has been gc'ed at that point).
Therefore, when the _SVGConverter gets gc'ed, both _tmpdir and _proc get gc'ed (in some non-specified order), but _tmpdir immediately wants to delete the directory, whereas the process managed by _proc will only terminate some time in the future, unless we explicitly both kill() and wait() it (from previous experience, even kill() is not enough -- there can be some small interval of time after kill() returns where the process hasn't actually exited yet).

This SO answer is helpful. Specifically, when using atexit, "what happens if a class is garbage collected before exit"? It seems that we should be able to perform cleanup solely withfinalize and skip the atexit as when this is called isn't always well defined wrt the class's lifespan.

But then again there's definitely a use for atexit as indicated by the comment:

        # Explicitly register deletion from an atexit handler because if we        # wait until the object is GC'd (which occurs later), then some module        # globals (e.g. signal.SIGKILL) has already been set to None, and        # kill() doesn't work anymore...

Using both seems unnecessary/redundant/prone to error as they are calling the same__del__ method at unknown times in the future.

Of note too isthis section from the docs:

Note: It is important to ensure that func, args and kwargs do not own any references to obj, either directly or indirectly, since otherwise obj will never be garbage collected. In particular, func should not be a bound method of obj.

So it seems that the function that finalize calls shouldn't be__del__ but instead a static/classmethod or a regular old function.

To be clear I'm not claiming my solution is best, just that it works empirically... but if you have something better, please open a PR :-)

Yeah, absolutely, this seems to work and should be merged. I don't have a better solution, I was just curious as to if one exists/ how the atexit and finalize interplay.

To be fair, the "best" solution would be to use these classes as context managers withwith, but that's hardly necessary...