[ python-Bugs-1717900 ] Destructor behavior faulty

[SourceForge.net]

Bugs item #1717900, was opened at 2007-05-12 20:41
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1717900&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Wolf Rogner (wrogner)
Assigned to: Nobody/Anonymous (nobody)
Summary: Destructor behavior faulty

Initial Comment:
I tried example 11.4. from bytesofpython (by C.H. Swaroop).
Example works fine.

Added a new Person instance 'wolf' -> Program terminated with:
Exception exceptions.AttributeError: "'NoneType' object has no attribute 'population'" in <bound method Person.__del__ of <__main__.Person instance at 0xb7d48d6c>> ignored

added print list(globals()) ->
['kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', 'wolf', '__name__', '__doc__']

changed wolf to aaa:

print list(globals()) ->
['aaa', 'kalam', '__builtins__', '__file__', 'DBGPHideChildren', 'swaroop', 'Person', '__name__', '__doc__']

Please note the position of 'aaa' at the beginning of the list, before 'Person'. With 'wolf' being after 'Person'.

If the destructing code removes items in this order, no wonder I get an error.

Person should not get deleted if refcount is still > 0.

Wolf Rogner


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-17 08:15

Message:
Logged In: YES 
user_id=849994
Originator: NO

Alan: you should bring that up on python-dev.

----------------------------------------------------------------------

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-16 22:58

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I tried out a simple change (to the trunk) in _PyModule_Clear to prevent
this particular problem.  Between the "remove everything beginning with an
underscore" and the "remove everything except __builtins__" steps, I added
a step to remove all instance objects in the module's dictionary.  It
appears to stop this problem and passes the regression test suite.  I can
post it as a patch if this seems like a reasonable change to make. 

Also, I noticed that earlier I posted the wrong link for the location of
the example code; it should have been:
     http://www.dpawson.co.uk/bop/byteofpython_120.txt

----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 22:06

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-16 11:19

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

----------------------------------------------------------------------

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-15 18:44

Message:
Logged In: YES 
user_id=479790
Originator: NO

FWIW, the script name appears to be relevant as well. I were going to say
that I could not reproduce it as it was; this same example saved as "a.py"
doesn't show the error; "w.py" does.

To the OP: Module finalization is a fragile step; this is a long standing
issue and could be improved, but anyway I don't think it can be made robust
enough (this is just my opinion!). I usually try to *never* reference any
globals in destructors. In this case, using self.__class__ instead of
Person is safer and works fine; if other globals were needed they could be
passed as default argument values.

----------------------------------------------------------------------

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-14 15:38

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I took the example mentioned from here: 
    http://www.python.org/doc/essays/cleanup/

and added this line to the end:

wolf = Person('wolf')

and it gives the reported error.  Here is a minimal snippet that produces
the same error when executed as the top-level module:

class Person:
        population = 0
        def __del__(self):
                Person.population -= 1

wolf = Person()


This appears to be consistent with the behavior described here:
     http://www.python.org/doc/essays/cleanup/

While I understand that cleaning up a module at exit time is probably not
an easy thing to make arbitrarily smart, this behavior seems a little too
not-smart to me.  It seems like it's not all that hard to get bitten by 
it, and the error makes no sense unless you're familiar with the module
cleanup algorithm.

For what it's worth, I offer to help make module cleanup a little smarter,
although I may not be able to spend much time on it until I finish some
things I'm already committed to do.

----------------------------------------------------------------------

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-12 23:36

Message:
Logged In: YES 
user_id=1115903
Originator: NO

Could you post the code for your entire script? It makes it a lot easier
to figure out what's going on.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1717900&group_id=5470