[Python-Dev] Class destructor

Nick Maclaren nmm1 at cus.cam.ac.uk
Fri Mar 2 10:23:58 CET 2007


"Guido van Rossum" <guido at python.org> wrote:
>
> Can you explain the reason for cleaning up in this scenario? Are you
> rapidly creating and destroying temporary class objects? Why can't you
> rely on the regular garbage collection process? Or does you class
> create an external resource like a temp file?

Effectively the latter.  The C level defines a meta-class, which is
instantiated with a specific precision, range etc. to derive the class
that can actually be used.  There can be an arbitrary number of such
derived classes, with different properties.  Very like Decimal, but
with the context as part of the derived class.

The instantiation creates quite a lot of constants and scratch space,
some of which are Python objects but others of which are just Python
memory (PyMem_Malloc); this is where an anonymous storage built-in
type would be useful.  The contents of these are of no interest to
any Python code, and even the objects are ones which mustn't be
accessed by the exported interfaces.

Also, on efficiency grounds, all of those need to be accessible by
C pointers from the exported class.  Searching by name every time they
are needed is far too much overhead.  Note that, as with Decimal, the
issue is that they are arbitrary sized and therefore can't simply be
put in the class structure.

Now, currently, I have implemented the suggestion of using the callback
on the C object that points to the structure that contains the pointers
to all of those.  I need to investigate it in more detail, because I
have had mixed success - that could well be the result of another bug
in my code, so let's not worry about it.

In THIS case, I am now pretty sure that I don't need any more, but I
can imagine classes where it wouldn't be adequate.  In particular,
THIS code doesn't need to do anything other than free memory, so I
don't care whether the C object attribute callback is called before
or after the class object is disposed of.  But that is obviously not
the case in general.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679


More information about the Python-Dev mailing list