RFC: Proposal: Deterministic Object Destruction
Richard Damon
Richard at Damon-Family.org
Sat Mar 3 12:37:08 EST 2018
On 3/3/18 11:33 AM, Michael Torrie wrote:
> On 03/03/2018 09:02 AM, ooomzay at gmail.com wrote:
>> I can assure you that RAII does what it says on the tin and is relied on in
>> many critical systems to release resources robustly ... given the
>> pre-requisite deterministic destruction.
> Sure but did you read what Paul Moore wrote? He said RAII works in C++
> because objects are allocated on the *stack* with strict lifetimes and
> scopes. They won't ever have cycles and they are guaranteed to be
> destroyed no matter what as the stack is unwound. Python has no
> stack-allocated objects.
>
> In C++, Heap-allocated objects must still be managed manually, without
> the benefit of RAII, for much of the same reasons as people are giving
> here for why RAII is not a good fit for Python. There are smart pointer
> objects that try to give RAII semantics to heap-allocated objects, with
> varying degrees of success. In other words there are some limitations.
>
> Python does not have stack-allocated objects, so the same issues that
> prevent RAII from automatically applying in C++ to heap objects exist here.
Yes, stack allocated object in C++ have a nice lifetime to allow RAII to
work, but it doesn't just work with stack allocated objects. A lot of
RAII objects are members of a class object that may well be allocated on
the heap, and RAII makes sure that all the needed cleanup gets done when
that object gets destroyed.
Yes, I suspect that directly creating a RAII control object as the sole
object on the heap is unusual, but that doesn't make the never appear on
the heap.
When the resource is memory, since one chunk of memory tends to be just
as usable as another, garbage collection works great. Other resources
can be quite precious, and delays in releasing them can have significant
effects. With RAII and immediate destruction on end of scope, we can
automate the release, without it and you need a lot of explicit code to
manage these resources. Maybe the issue is that most Pythonic code
doesn't need to deal with these sorts of resources where this becomes
important to be dealt with automatically, either being held for the
whole program so OS cleanup handles it, or the are so fine grained that
the explicitness isn't an issue.
--
Richard Damon
More information about the Python-list
mailing list