On Sat, Mar 3, 2018 at 11:58 AM, Michael Torrie <torr...@gmail.com> wrote: > On 03/02/2018 08:36 AM, Paul Moore wrote: >> On 2 March 2018 at 15:09, <ooom...@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 -- https://mail.python.org/mailman/listinfo/python-list