Consider explicit deletion of stream objects on exit

[bskinn]

Depends on the balance between the number of times stdio_mgr is used, the frequency of calls, and the frequency of suitable garbage collection.

Prompted by this SO answer. That example uses a class for the context manager, though, with a recommendation to retain the instance for storing the captured stream contents. With stdio_mgr being implemented as a function, especially one where the streams are closed on context exit, there may not be as big of a problem with memory consumption.

[jayvdb]

#3 is sort of related, and on its way to being solved.

I think .close() would have similar effect on memory consumption, as all buffers are released, but worth checking.

[bskinn]

In most modern contexts, for anything but the most ridiculous of large streams, I can't imagine this Issue is likely to be a big issue. Seems very YAGNI.

Especially with the changes from #25 and #26, though -- as you noted at the bottom of #26, the mocked stream objects are now storing internal references to the underlying buffers in some situations, and that could lead to memory accumulation if enough things stay in scope/have references.

[bskinn]

Although -- both RandomTextIO and TeeStdin store a reference to the buffer in ._buf... as long as the (i, o, e) objects remain in scope, I would think they will retain references to their ._bufs the whole time, even after .close() or .detach(), right?

I guess .close() frees the actual buffer memory, so in that case it is just ._closed_buf to worry about in terms of memory consumption.

But for .detach(), I'd think it would still matter -- though, if someone is .detach()-ing, they likely still want to work with the stream data, and so it would probably be a total footgun to wipe the buffer after just a .detach().

So, yeah: just ._closed_buf to worry about, then.

[bskinn]

With #58 switching the persisted-content mechanism from ._closed_buf to a callback, this issue should be moot.

[jayvdb]

I think we at least need tests for this, and it turns out to be very important to delete objects when using TemporaryFile and when using the real sys handles.