[ python-Bugs-1500167 ] interpret termination, object deleting

SourceForge.net noreply at sourceforge.net
Sun Jun 4 21:56:48 CEST 2006


Bugs item #1500167, was opened at 2006-06-03 20:55
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1500167&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: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jan Martinek (johnymart)
Assigned to: Nobody/Anonymous (nobody)
Summary: interpret termination, object deleting

Initial Comment:
Hello,

I found out a strange behavior. This code

#!/usr/bin/python
class M:
  b = 0
  def __del__(self):
    M.b = 0

a1 = M()

results in exception when the program terminates.

Exception exceptions.AttributeError: "'NoneType' object
has no attribute 'b'" in <bound method M.__del__ of
<__main__.M instance at 0x2aaaaab50a28>> ignored

Note that the code must be run from an executable file
-not from the python interpretter. Otherwise the
exception is not thrown.

An interesting thing is that changing the last line to

a = M()

also prevents python from throwing the exception. Why
does it depend on variable's name?

bye
Jan Martinek

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

>Comment By: Martin v. Löwis (loewis)
Date: 2006-06-04 21:56

Message:
Logged In: YES 
user_id=21627

On shutdown time, Python clears each module by replacing all
module entries with None. So at some point, it does
  a1 = None # or a1 = None
and at some other point, it does
  M = None
Depending on the order in which these happen, M might be
None (i.e. might not be class M anymore) when __del__ runs.

The order in which these happen depends on the order which
the names have in the module's dict. This, in turn, depends
on the hash values of the strings, modulo the size of the
dictionary. Apparently, "a1" gets hashed after "M", but "a"
gets hashed before "M".

This isn't really a bug, atleast not one that we plan to
fix. The order in which modules get emptied is unspecified,
and it can easily happen that things are gone when some
destructor runs. Classes should be written to be resistent
against this behaviour, e.g. by writing

  def __del__(self):
    self.__class__.b = 0 # name "M" might be gone already

Closing this as "won't fix".


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

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


More information about the Python-bugs-list mailing list