RFC: Proposal: Deterministic Object Destruction

Chris Angelico rosuav at gmail.com
Fri Mar 2 22:28:18 EST 2018


On Sat, Mar 3, 2018 at 11:58 AM, Michael Torrie <torriem at gmail.com> wrote:
> On 03/02/2018 08:36 AM, Paul Moore wrote:
>> On 2 March 2018 at 15:09,  <ooomzay at gmail.com> wrote:
>>> We must be discussing a different RAII. That is the raison d'etre of RAII: RAII directly addresses this problem in an exception-safe way that does not burden the resource user at all.
>>
>> RAII works in C++ (where it was initially invented) because it's used
>> with stack-allocated variables that have clearly-defined and limited
>> scope. In my experience writing C++, nobody uses RAII with
>> heap-allocated variables - those require explicit allocation and
>> deallocation and so are equivalent to having an explicit "close()"
>> method in Python (or using __del__ in CPython as it currently exists).
>
> Very good point.  I'm not sure the OP considered this when proposing
> this idea.
>
> That said, In C++, there are a number of ways of making heap-allocated
> objects more RAII-like. These include smart pointers that do reference
> counting and reference borrowing.  They work pretty well when used as
> designed, but they do require some programmer understanding and
> intervention to use correctly and leaks can and do happen.  Smart
> pointers are pretty good hacks as far as they go, without a garbage
> collector.

Ref-counting smart pointers? They might save you the trouble of
calling (the equivalents of) Py_INCREF and Py_DECREF manually, but
they still don't solve reference loops, and they don't deal with the
termination cleanup problem. Smart pointers don't change heap
allocation semantics and don't remove the garbage collector; all they
do is change the way you do refcounting. (Which is not a bad thing,
btw. I've used smart pointers, and they can be very helpful. But
they're no panacea.)

ChrisA



More information about the Python-list mailing list