[Python-Dev] Class destructor (original) (raw)

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