[Python-Dev] Object finalization for local (ie function) scopes

Oliver Schoenborn oliver.schoenborn at utoronto.ca
Thu Jun 10 17:07:22 EDT 2004

From: "Martin v. Löwis" <martin at v.loewis.de>
> Oliver Schoenborn wrote:
> > So it seems that having a __del__ is ok *most* of the time, and that if
> > find a mem leak, verify if you have cyclical refs, and modify algorithm
> > break cycle because gc won't be able to call __del__; however if an
> > exception gets thrown, you can't rely on __del__ getting called. Since
> > exceptions are so common, I have to conclude that you can never rely on
> > __del__ to free resources. Where am I wrong in this reasoning?
> Yes, you are wrong. The Python language specification does not make
> guarantees. However, specific implementations do make specific
> guarantees beyond what the language specification guarantees.

Which means nothing because if I code in Python, code portability is a major
concern. Any aspects of the language that are not in the specification must
be avoided, so if specs don't guarantee s/m, no one in their right mind
would use that s/t.

> Your proposed mechanism cannot be added to the Python language
> specification because there might be Python implementations for
> which the mechanism is difficult to implement.

I can accept that only if there is something inherent to the technique which
exploits a non-specified aspect of the language. I can't think of any. Could
you be more specific about what aspect is not portable?

If it is portable, then since it works as-is in Python, it could be put into
the specs. At the very least, Python interpreter implementers who can't
implement right into the interpreter could provide it as a module, like it
is now (and as it would be anyways, so that the front end never changes, a
bit like weakref).


More information about the Python-Dev mailing list