Duncan Booth wrote:
DB> BTW, the behaviour is completely different if you use a new style class,
DB> but still somewhat bizarre: for new style classes only the first 25
objects
DB> get freed when you clear a, the remainder are only released by the
garbage
DB> collector.
If to add the
Duncan Booth wrote:
DB> I figured out what is going on in the code to deallocate an old-style
class
DB> instance:
DB>
DB> The reference count is temporarily incremented.
DB>
DB> If the class has a __del__ method then a descriptor is created for the
DB> method and called. When the
Duncan Booth wrote:
DB> You should post a working code sample which generates your output if you
DB> want a more useful answer.
Hello!
Today I have found a compact variant of a code which shows my question:
---
#!/usr/local
Duncan Booth пишет:
DB> Not with the code which you gave as an example, but in the general case
DB> yes, the only guarantee that Python gives about the __del__ method on an
DB> instance is that it will be called zero, one or more than one times
during
DB> the run of the program. In pra
Max Yuzhakov writes:
MY> print "difference = %d" % init_cnt-del_cnt
Little correction.
print "difference = %d" % (init_cnt-del_cnt)
--
GMT More Then ...
--
http://mail.python.org/mailman/listinfo/python-list
Hello!
It is correct behaviour for python to call __del__ on some
identity of a class object more than once?
In brief I shall describe a situation. Sorry for my english.
For debugin purposes I'm put in my module global counters
for counting __init__ and __del__ calls.
This is a sample code for
