473,883 Members | 1,798 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

It is __del__ calling twice for some instances?

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 clearness:
-------------------------------------------------------
init_cnt = 0
del_cnt = 0

class foo:
def __init__(self):
global init_cnt
init_cnt += 1

def __del__(self):
global del_cnt
del_cnt += 1

def stat():
print "init_cnt = %d" % init_cnt
print "del_cnt = %d" % del_cnt
print "difference = %d" % init_cnt-del_cnt
-------------------------------------------------------
And the result of a stat() call in some moment of time
looks like so:

init_cnt = 6233
del_cnt = 6234
difference = -1

It is __del__ called twice for some instance?

Thanks in advance!
--
GMT More Then ...
Aug 16 '06 #1
10 3224
Max Yuzhakov writes:

MY print "difference = %d" % init_cnt-del_cnt

Little correction.

print "difference = %d" % (init_cnt-del_cnt)
--
GMT More Then ...
Aug 16 '06 #2
Max Yuzhakov wrote:
This is a sample code for clearness:
that code snippet doesn't create any foo() instances, what I can see...

</F>

Aug 16 '06 #3
Max Yuzhakov wrote:
It is correct behaviour for python to call __del__ on some
identity of a class object more than once?
Not with the code which you gave as an example, but in the general case
yes, the only guarantee that Python gives about the __del__ method on an
instance is that it will be called zero, one or more than one times during
the run of the program. In practice there are various situations where
__del__ will not be called, but it is only called multiple times if you
resurrect the object during a call to __del__.

The output from your stat function could, of course, also be generated by
creating and destroying lots of foo objects in another thread. If a foo was
both created and destroyed between the first two print statements, and
another one was created and destroyed in the middle of the evaluation of
the last print statement then you could see the output you described
without any multiple __del__ calls in the same object.

You should post a working code sample which generates your output if you
want a more useful answer.

Aug 16 '06 #4
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 practice there are various situations where
DB __del__ will not be called, but it is only called multiple times if you
DB resurrect the object during a call to __del__.

No, only presented code in __del__ do
increment of global variable del_cnt.

DB The output from your stat function could, of course, also be generated by
DB creating and destroying lots of foo objects in another thread. If a foo was
DB both created and destroyed between the first two print statements, and
DB another one was created and destroyed in the middle of the evaluation of
DB the last print statement then you could see the output you described
DB without any multiple __del__ calls in the same object.

No, it's a single-threaded code.

DB You should post a working code sample which generates your output if you
DB want a more useful answer.

I'm sorry for mess with a code. I have forgotten to write, that is
only fragments for demonstration of essence of a question.

Real code in this module has 880 lines and I shall not
abuse your time. I shall try to solve a problem by debuger.

And thank for Your answer!
--
GMT More Then ...
Aug 16 '06 #5
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/bin/python -d
# -*- coding: koi8-u -*-

class foo:
def __init__(self, other):
self.other = other

global ini_cnt
ini_cnt +=1

def __del__(self):
global del_cnt
del_cnt +=1

def stat():
print "-"*20
print "ini_cnt = %d" % ini_cnt
print "del_cnt = %d" % del_cnt
print "difference = %d" % (ini_cnt-del_cnt)

ini_cnt = 0
del_cnt = 0
loop_cnt = 75

a = foo(None)

for i in xrange(loop_cnt ):
a = foo(a)

stat()
a = None
stat()
-----------------------------------------------------------------------

And result is:
--------------------
ini_cnt = 76
del_cnt = 0
difference = 76
--------------------
ini_cnt = 76
del_cnt = 77
difference = -1

Why for some instance __del__ called twice?
Such behaviour of __del__ seems to me unpredictable.

Thanks for Your attention!
--
GMT More Then ...
Aug 17 '06 #6
Max Yuzhakov wrote:
Why for some instance __del__ called twice?
Such behaviour of __del__ seems to me unpredictable.
Here's a slightly modified version of your code. The 51st object destroyed
gets its __del__ method called twice. It doesn't matter how long your loop
is, every 50th object gets special treatment (or perhaps it is the 49th).

The good news is that there is a way to stop it happening: just add an
explicit "del self.other" at the end of __del__. The bad news is that if
your list is too long that will cause a flood of error messages and won't
call the destructors at all past the first 1000.

As to why it happens, there is a mechanism in Python to stop unlimited
stack being used when objects are freed: when the stack gets too deep then
instead of being released, the Py_DECREF call puts the object into a
trashcan list and the objects aren't released until the stack has unwound.
It looks like there must be a bug round the trashcan mechanism somewhere.

BTW, the behaviour is completely different if you use a new style class,
but still somewhat bizarre: for new style classes only the first 25 objects
get freed when you clear a, the remainder are only released by the garbage
collector.

#!/usr/local/bin/python -d
# -*- coding: koi8-u -*-

class foo:
def __init__(self, other):
self.other = other
self._deleted = False

global ini_cnt
ini_cnt +=1

def __del__(self):
if self._deleted:
print "aargh!"
self._deleted = True
global del_cnt
del_cnt +=1
print "del",del_cnt," at",id(self)

def stat():
print "-"*20
print "ini_cnt = %d" % ini_cnt
print "del_cnt = %d" % del_cnt
print "difference = %d" % (ini_cnt-del_cnt)

ini_cnt = 0
del_cnt = 0
loop_cnt = 54

a = foo(None)

for i in xrange(loop_cnt ):
a = foo(a)

stat()
a = None
stat()

Aug 18 '06 #7
Duncan Booth wrote:
As to why it happens, there is a mechanism in Python to stop unlimited
stack being used when objects are freed: when the stack gets too deep
then instead of being released, the Py_DECREF call puts the object
into a trashcan list and the objects aren't released until the stack
has unwound. It looks like there must be a bug round the trashcan
mechanism somewhere.
I figured out what is going on in the code to deallocate an old-style class
instance:

The reference count is temporarily incremented.

If the class has a __del__ method then a descriptor is created for the
method and called. When the call returns, the descriptor is released.

Then the object itself is released using special code to avoid a recursive
call to the deallocator.

However, if the trashcan mechanism is invoked by the attempt to release the
descriptor, it actually queues the descriptor in the trashcan. Since the
descriptor contains a reference to the object it has effectively
resurrected it. This means the special code to avoid the recursive call
simply decrements the reference count but does not release anything (the
object has been resurrected by the descriptor). When the descriptor is
later released the __del__ method is triggered a second time.
Aug 18 '06 #8

Duncan Booth wrote:
Duncan Booth wrote:
As to why it happens, there is a mechanism in Python to stop unlimited
stack being used when objects are freed: when the stack gets too deep
then instead of being released, the Py_DECREF call puts the object
into a trashcan list and the objects aren't released until the stack
has unwound. It looks like there must be a bug round the trashcan
mechanism somewhere.

I figured out what is going on in the code to deallocate an old-style class
instance:

The reference count is temporarily incremented.

If the class has a __del__ method then a descriptor is created for the
method and called. When the call returns, the descriptor is released.

Then the object itself is released using special code to avoid a recursive
call to the deallocator.

However, if the trashcan mechanism is invoked by the attempt to release the
descriptor, it actually queues the descriptor in the trashcan. Since the
descriptor contains a reference to the object it has effectively
resurrected it. This means the special code to avoid the recursive call
simply decrements the reference count but does not release anything (the
object has been resurrected by the descriptor). When the descriptor is
later released the __del__ method is triggered a second time.
This looks like some good code to add to the python unit tests.
>From your description, it appears the problem is that the object is
placed in the trashcan after calling __del__ once. Perhaps the choice
to place it in the trashcan could be made instead of calling __del__
the first time, rather than after calling __del__?

Regards,
Pat

Aug 18 '06 #9
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 call returns, the descriptor is released.
DB>
DB Then the object itself is released using special code to avoid a recursive
DB call to the deallocator.
DB>
DB However, if the trashcan mechanism is invoked by the attempt to release the
DB descriptor, it actually queues the descriptor in the trashcan. Since the
DB descriptor contains a reference to the object it has effectively
DB resurrected it. This means the special code to avoid the recursive call
DB simply decrements the reference count but does not release anything (the
DB object has been resurrected by the descriptor). When the descriptor is
DB later released the __del__ method is triggered a second time.

Thank You for so detailed explanation!
--
GMT More Then ...
Aug 18 '06 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
1650
by: Kepes Krisztian | last post by:
Hi ! I very wonder, when I get exp. in java with GC. I'm Delphi programmer, so I get used to destructorin objects. In Java the final method is not same, but is like to destructor (I has been think...). And then I try with some examples, I see, that the Java GC is
0
1159
by: John Hunter | last post by:
I have a class that uses some extension code I have written and I am trying to track down some memory leaks, which I presume to be in my extension code. The class is question is in a python module, not extension code. I notice some strange behavior; perhaps a guru can give me a pointer about what this may mean. If I define the __del__ method in the class C class C: ...lots of other stuff...
2
1439
by: David MacQuigg | last post by:
I'm __del__() to decrement a count of instances of a class whenever an instance is deleted, and I'm getting very erratic behavior. This is in CPython, which I am told has no problem with reference counts getting out-of-sync with the deletion of instances. The behavior of __del__() seems to be very sensitive to the exact sequence of commands. The example below is a repeatable test case. It might be possible to simplify this further,...
4
6545
by: Baoqiu Cui | last post by:
Today I was playing with a small Python program using Python 2.4 on Cygwin (up-to-date version, on Windows XP), but ran into a strange error on the following small program (named bug.py): ------------------------------- #!/usr/bin/python class Person: population = 0 def __del__(self):
0
1143
by: phil | last post by:
> you haven't answered my question, btw: why are you using __del__ > to do something that the garbage collector should do for you? After more reading it seems I have made an ass of my self on this subject. Here is my problem at length. I teach high school geometry. I have created a program with a scalable graph on which to make drawings to illustrate concepts. This is working well.
13
1419
by: Torsten Bronger | last post by:
Hallöchen! When my __del__ methods are called because the program is being terminated, I experience difficulties in calling functions that I need for a clean shutdown of my instances. So far, there has been only one of these functions, and a class-local alias solved the problem. However, now there are many of them. Is there a way to detect whether the program is being terminated? (In this case, I wouldn't care and return from...
14
1307
by: Chris Curvey | last post by:
I need to ensure that there is only one instance of my python class on my machine at a given time. (Not within an interpreter -- that would just be a singleton -- but on the machine.) These instances are created and destroyed, but there can be only one at a time. So when my class is instantiated, I create a little lock file, and I have a __del__ method that deletes the lock file. Unfortunately, there seem to be some circumstances...
8
8401
by: Gregor Horvath | last post by:
Hi, I do not understand why __del__ does not get executed in the following example. test.py: #!/usr/bin/python class A(object): def __init__(self):
6
2880
by: George Sakkis | last post by:
I'm baffled with a situation that involves: 1) an instance of some class that defines __del__, 2) a thread which is created, started and referenced by that instance, and 3) a weakref proxy to the instance that is passed to the thread instead of 'self', to prevent a cyclic reference. This probably sounds like gibberish so here's a simplified example: ==========================================
0
9942
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9792
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11142
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10745
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10417
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9575
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7972
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5992
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
4221
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.