RFC: Proposal: Deterministic Object Destruction
Ooomzay
ooomzay at gmail.com
Tue Mar 6 17:09:53 EST 2018
On Monday, 5 March 2018 23:06:53 UTC, Steven D'Aprano wrote:
> On Mon, 05 Mar 2018 09:22:33 -0800, Ooomzay wrote:
> [...]
> > If you would like to have a shot at coding this without RAII, but
> > preserving the OO design, you will find that it is considerably
> > simpler than the with/context manager approach.
>
> Preserving the OO design, you say? Okay, since my application apparently
> isn't allowed to know that it is processing two files, I'll simply
> delegate that to the object:
>
> class C(A, B):
> def run(self):
> with open(self.a) as a:
> with open(self.b) as b:
> process(a, b)
>
> # Later.
> if __name__ = '__main__':
> # Enter the Kingdom of Nouns.
> c = C()
> c.run()
>
> There you go. Encapsulation and OO design.
1. This does not execute. It is only when you actually flesh out
these deliberately minimal classes A, B & C with PEP232 paraphernalia
that we all be able to see clearly how much cleaner or messier
things are with PEP232.
2. Your Class C breaks A & B's encapsulation by inheriting rather than
composing them. Apart from increasing coupling and preventing
substitution, C contained A & B in this example to illustrate that there is
no RAII related burden whatever_on this intermediate class as
it manages no external resources directly. It does not even
need to implement __del__.
3. You have assumed a single threaded application. Please imagine
that A and B are classes managing some remote valves and maintain
their own threads as well as a serial port for comms. And C is there to
coordinate them towards some greater purpose.
If you would like to try and add PEP232 support to
classes A,B & C to the point that you can create
and destroy c = C() in an exception-safe way we may
all learn something.
> I'm not trying to dissuade you from using RAII in your own applications,
> if it works for you, great.
Unfortunately, despite having conquered it, without a _guarantee_ of this
behaviour from the language, or at least one mainstream implementation,
I will not invest in python again. Nor recommend any one else with a serious
real world resource management application to do so. This was the original
motive for my PEP.
More information about the Python-list
mailing list