RFC: Proposal: Deterministic Object Destruction

[Steven D'Aprano]

On Mon, 05 Mar 2018 09:22:33 -0800, Ooomzay wrote:

[...]
>> Looking at that code, my major thought is  that there is far too much
>> OO design, not enough simplicity.
> 
> If this is far too much OO for you then RAII will be of no interest to
> you.

I think this is probably the wisest thing you have said in this entire 
discussion. OO design is often over-rated and elevated to the position of 
Holy Writ, full of over-engineered design patterns needed to overcome the 
flaws of OO design. I see no reason to design my application using OO 
principles when they aren't needed.

You say you have had great success with the RAII pattern in your own 
Python code. Great! I mean that sincerely. I'm really happy for you. But 
you now want to force that on *everyone*, even onto implementers where 
this will be an enormous burden to re-write their interpreter from the 
ground up to add a reference counter.

Why?

Do you have even the tiniest interest in running your RAII application 
under IronPython or Jython? Why do you care that your code, using CPython-
only features, must be portable to other implementations?

If your PEP is accepted, will you be volunteering your time for the next 
two or four years to re-write Jython and IronPython? To say nothing of 
PyPy and possibly Stackless?

CPython does what you want. So be satisfied that if you target CPython, 
you can use the RAII pattern to your heart's desire.


[...]
>> Perhaps I'm missing something, but I have no idea what benefit there is
>> in that style of code over:
>> 
>> with open('a') as a:
>>     with open('b') as b:
>>         process(a, b)
> 
> Encapsulation. Your application code is now managing details that should
> be hidden in the object. This PEP and RAII are unashamedly targeted at
> OO designs.

Encapsulation for the sake of encapsulation leads to monstrously over-
engineered heights of abstraction. Without a concrete use-case, I have no 
confidence that this *should* be "hidden in the object". Even if it 
should, I have no confidence that this specific design for encapsulation 
and/or data hiding[1] (they aren't the same thing) is the best design.


> 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.

Look, I'm sure that we could go back and forth for weeks trading more and 
more complicated, convoluted, esoteric or just plain unlikely scenarios 
leading up to the conclusion you want. I'm even willing to accept for the 
sake of discussion that in *your specific application's case*, you have 
come up with the best possible solution.

I'm not trying to dissuade you from using RAII in your own applications, 
if it works for you, great.

But I think it is unjustified to try to force that on all implementers 
unless you have a real need, not just as a matter of principle, to use 
RAII while still insisting on your code being implementation independent.


[...]
> If you choose RAII you will not be cavalier with your references.

You mean, "if you choose RAII, you cannot afford to be cavalier with your 
references, because if you fail to meet the rigorous demands of this 
pattern, your code will be buggy".

CPython has a long history of people relying on RAII and ending up with 
buggy code that doesn't close resources in a timely manner. The reason 
the with statement was invented was to be a simple and effective 
alternative to the RAII pattern, which promises the world in theory and 
fails to deliver in practice when it runs up against the reality that 
most people *are* cavalier with their references.

Not for you, obviously. I'm glad that it works for you. But as a 
community, we've been there and done that.




[1] They aren't the same thing.

-- 
Steve