Memory leaks in VC6 2 line Python 2.1b1 apps?

[Tim Peters]

[Craig Holman]
> I'm afraid that both versions 2.0 and 2.1b1 leak memory for a single
> Py_Initialize, Py_Finalize sequence in a Visual C++ MFC application.

The bad news is that there are legit bugs in 2.0 here.  The good/bad news is
that it's got nothing to do w/ MFC (it's much the same on all platforms).
The bad/good news is that 2.1b1 appears to be "leaking" exactly as much as
it's designed to "leak".

> ...
> Python 2.1b1 had 21 memory leaks that resulted in a leakage of a
> total of 6,899 bytes for a single pair of Py_Initialize, Py_Finalize
> calls.  Additional Py_Intitialize, Py_Finalize pairs did not result
> in any additional leakage (10,000 pairs were tested).

Then it's functioning as designed.  Python has no protocol to let modules
know that Python is shutting down, so any number of file statics "leak" at
shutdown.  However, modules are also written so as to reuse those guys at the
next Py_Initialize, so they're "leaks" in a mostly academic sense; i.e., the
cost of hunting all of them down is thought higher than the benefits of
killing them.  Besides, we could well end up with more than 7Kb of runtime
code to track down and nuke that 7Kb of data you're seeing!  So long as
additional (beyond the first) Init/Fini pairs don't systematically leak
additional memory, we're happy enough.

> ,,,
> I'm hoping that some of these leaks can be addressed before the 2.1
> release is issued.

It's unlikely unless somebody submits "obviously safe" patches.  Most leaks
now appear due to interned strings, and I'll push a bit to get those cleaned
up (they already are in 2.1b1, but only when Barry is running *his* leak
tests under Insure++).

the-question-is-how-python-knows-when-barry-is-running-it-ly y'rs  - tim