Tim Peters wrote:
> Putting a collection call inside an initialize/finalize loop isn't
> doing it late, it's doing it early. If we can't collect cyclic trash
> after Py_Initialize(), that would be a showstopper for apps embedding
> Python "in a loop"! There's either nothing to fear here, or Pytho
[Tim]
>> Because new-style classes create cycles that Py_Finalize() doesn't
>> clean up, it may make analysis easier to stick a PyGC_Collect() call
>> (or two! repeat until it returns 0) inside the loop now.
[Martin]
> I'm shy to do this: the comment in Py_Finalize suggests that things
> will bre
Tim Peters wrote:
> Because new-style classes create cycles that Py_Finalize() doesn't
> clean up, it may make analysis easier to stick a PyGC_Collect() call
> (or two! repeat until it returns 0) inside the loop now.
I'm shy to do this: the comment in Py_Finalize suggests that things
will break i
[Martin]
> Running Py_Initialize/Py_Finalize once leaves 2150 objects behind (on
> Linux). The second run adds 180 additional objects; each subsequent
> run appears to add 156 more.
One thing I notice is that they're all > 0 :-) I believe that, at one
time, the second and subsequent numbers were
Martin v. Löwis wrote:
> Tim Peters wrote:
>> Well, there may well be a bug (or multiple bugs) underlying that one
>> too. It's one thing for Py_Finalize() not to release all memory (it
>> doesn't and probably never will), but it's not necessarily the same
>> thing if running Py_Initialize() ... P
Tim Peters wrote:
> Well, there may well be a bug (or multiple bugs) underlying that one
> too. It's one thing for Py_Finalize() not to release all memory (it
> doesn't and probably never will), but it's not necessarily the same
> thing if running Py_Initialize() ... Py_Finalize() repeatedly keeps
[Martin v. Löwis]
> Several places in the documentation claim that Py_Finalize will
> release all memory:
>
> http://docs.python.org/api/embedding.html
>
> says that literally,
It's wrong ;-).
> and
>
> http://docs.python.org/api/initialization.html#l2h-778
>
> suggests it is a bug when memory is
Guido van Rossum wrote:
> I'm afraid it was wishful thinking on my part.
>
> The best we can try to hope for is to ensure that repeatedly calling
> Py_Initialize and Py_Finalize doesn't leak too much memory.
Ok. Unless somebody still claims to the contrary, I will go ahead
and weaken the promises
I'm afraid it was wishful thinking on my part.
The best we can try to hope for is to ensure that repeatedly calling
Py_Initialize and Py_Finalize doesn't leak too much memory.
--Guido
On 4/11/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Several places in the documentation claim that Py_Fin
Several places in the documentation claim that Py_Finalize will
release all memory:
http://docs.python.org/api/embedding.html
says that literally, and
http://docs.python.org/api/initialization.html#l2h-778
suggests it is a bug when memory is not freed in Py_Finalize.
This has left people to be
10 matches
Mail list logo
