RFC: Proposal: Deterministic Object Destruction

Steven D'Aprano steve+comp.lang.python at pearwood.info
Wed Feb 28 18:48:23 EST 2018


On Wed, 28 Feb 2018 14:51:09 -0800, ooomzay wrote:

> Informal Background
> ===================
> 
> Python's lack of Deterministic Object Destruction semantics strikes me
> as very unpythonic. This state of affairs spawns lengthy diatribes on
> __del__(), 

I've never seen any of these lengthy diatribes. If they're on your blog, 
you may be over-estimating how many readers you have.


> malignant carbuncles such as PEP 343 (the "with"statement).

Ah, this is going to be one of *those* posts.


> This PEP proposes that valid python interpreters *must* synchronously
> destroy objects when the last reference to an object goes out of scope.

Well, that rules out any practical Python interpreter running on the Java 
or .Net virtual machines, not to mention banning advanced and modern 
garbage collectors unless they also include a reference counter.

So that's Jython and IronPython out, and PyPy's useful work on 
alternative garbage collectors out the window. It also enshrines the GIL 
(or some other locking mechanism) as not just an implementation detail of 
CPython, but as mandatory for all Python interpreters.


> Motivation
> ==========
> 
> To make the elegance (simplicity, generality, and robustness) of the
> "Resource Acquisition Is Initialization" (RAII) idiom available to all
> python applications and libraries.

I've never yet seen an explanation of RAII that makes the least amount of 
sense. I wouldn't call it either elegant or simple. More like "confusing 
and badly named".


> Specification
> =============
> 
> When the last reference to an object goes out of scope the intepreter
> must synchronously, in the thread that releases the last reference,
> invoke the object's __del__() method and then free the memory occupied
> by that object.

What happens if the __del__ method recreates a reference to the object?


> Backwards Compatibility
> =======================
> 
> This proposal preserves 100% backwards compatibility.

So long as you're not using IronPython, Jython, or some alternate builds 
of PyPy.


-- 
Steve




More information about the Python-list mailing list