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
--
https://mail.python.org/mailman/listinfo/python-list
