Re: RAII vs gc (was fortran lib which provide python like data type)
Sturla Molden wrote:
Rustom Mody rustompm...@gmail.com wrote:
The case of RAII vs gc is hardly conclusive:
http://stackoverflow.com/questions/228620/garbage-collection-in-c-why
The purpose of RAII is not to be an alternative to garbage collection
(which the those answers imply), but to ensure deterministc execution of
setup and tear-down code. The Python equivalent of RAII is not garbage
collection but context managers.
Those answers is a testimony to how little the majority of C++ users
actually understand about the language.
A C++ statement with RAII like
{
Foo bar();
// suite
}
is not equivalent to
bar = Foo()
in Python. It actually corresponds to
with Foo() as bar:
suite
Nice answer! I'm not qualified to tell whether you are right or not, but
what you say has the ring of truth about it.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: RAII vs gc (was fortran lib which provide python like data type)
On Fri, Jan 30, 2015 at 1:28 PM, Sturla Molden sturla.mol...@gmail.com wrote:
in Python. It actually corresponds to
with Foo() as bar:
suite
The problem with with statements is that they only handle the case of
RAII with stack allocated variables, and can't handle transfer of
ownership cleanly.
Consider the case of a function that opens a file and returns it:
def myfunction(name, stuff):
f = open(name)
f.seek(stuff) # or whatever
return f
def blahblah():
with myfunction('hello', 12) as f:
This code is wrong, because if an error occurs during seek in
myfunction, the file is leaked.
The correct myfunction is as follows:
def myfunction(name, stuff)
f = open(name)
try:
f.seek(stuff)
except:
f.close()
raise
Or whatever. (I would love a close_on_error context manager, BTW.)
With RAII, the equivalent C++ looks nearly exactly like the original
(bad) Python approach, except it uses unique_ptr to store the file,
and isn't broken. (Modern) C++ makes this easy to get right. But
then, this isn't the common case.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
Re: RAII vs gc (was fortran lib which provide python like data type)
On Sun, Feb 1, 2015 at 2:00 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
A C++ statement with RAII like
{
Foo bar();
// suite
}
is not equivalent to
bar = Foo()
in Python. It actually corresponds to
with Foo() as bar:
suite
Nice answer! I'm not qualified to tell whether you are right or not, but
what you say has the ring of truth about it.
I would say that this is indeed correct, with the caveat that RAII is
most often used for memory allocation, in which case the correct
transformation into Python _would_ be a constructor call. But when you
use this kind of thing to set up state and clean up afterwards, then
yes, Python's equivalent would be a context manager.
So a C++ way to release and reacquire the GIL might look like this
(borrowing from https://docs.python.org/3.5/c-api/init.html):
class ReleaseGIL
{
//Internal state
PyThreadState *_save;
public:
//Constructor
ReleaseGIL() {_save = PyEval_SaveThread();}
//Destructor
~ReleaseGIL() {PyEval_RestoreThread(_save);}
};
//Usage example:
int do_work()
{
while (1)
{
//use the Python C API to figure out what we need to do
ReleaseGIL heavy_processing_coming;
//do the heavy computational work
} //GIL is reacquired here
}
The Python equivalent would be something like:
@contextlib.contextmanager
def release_gil():
Why the bleep are we manipulating the
GIL from Python code anyway???
_save = PyEval_SaveThread()
yield
PyEval_RestoreThread(_save)
def do_work()
while True:
# get some work
with release_gil() as heavy_processing_coming:
# do the heavy computational work
# GIL is reacquired here
In each case, you have a guarantee that code following the suite will
not be executed without first performing the appropriate cleanup.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: RAII vs gc (was fortran lib which provide python like data type)
Rustom Mody rustompm...@gmail.com wrote:
The case of RAII vs gc is hardly conclusive:
http://stackoverflow.com/questions/228620/garbage-collection-in-c-why
The purpose of RAII is not to be an alternative to garbage collection
(which the those answers imply), but to ensure deterministc execution of
setup and tear-down code. The Python equivalent of RAII is not garbage
collection but context managers.
Those answers is a testimony to how little the majority of C++ users
actually understand about the language.
A C++ statement with RAII like
{
Foo bar();
// suite
}
is not equivalent to
bar = Foo()
in Python. It actually corresponds to
with Foo() as bar:
suite
Sturla
--
https://mail.python.org/mailman/listinfo/python-list
RAII vs gc (was fortran lib which provide python like data type)
On Friday, January 30, 2015 at 11:01:50 PM UTC+5:30, Rustom Mody wrote: On Friday, January 30, 2015 at 10:39:12 PM UTC+5:30, Michael Torrie wrote: On 01/30/2015 09:27 AM, Rustom Mody wrote: ... if I restate that in other words it says that sufficiently complex data structures will be beyond the reach of the standard RAII infrastructure. Of course this only brings up one side of memory-mgmt problems viz. unreclaimable memory. What about dangling pointers? C++ apps are prone to segfault. Seems to suggest (to me at least) that the memory-management infrastructure is not right. Stroustrup talks of the fact that C++ is suitable for lightweight abstractions. In view of the segfault-proneness I'd say they are rather leaky abstractions. But as I said at the outset I dont understand C++ Yes I can tell you haven't used C++. Compared to C, I've always found memory management in C++ to be quite a lot easier. The main reason is that C++ guarantees objects will be destroyed when going out of scope. I hear you and I trust you as a gentleman but I dont trust C++ :-) The only time in some near 15 years of python use that I got it to segfault was when Ranting Rick gave some wx code to try [at that time he was in rant-against-tk mode] Sure enough it was related to the fact that wx is written in C++ and some expectations were not being followed. So when designing a class, you put any allocation routines in the constructor, and put deallocation routines in the destructor. And it just works. This is something I miss in other languages, even Python. And for many things, though it's not quite as efficient, when dealing with objects you can forgo pointers altogether and just use copy constructors, instead of the blah *a = new blah_with_label(hello) //allocate on heap //forget to delete a and it leaks the heap *and* anything //that class blah allocated on construction. just simply declare objects directly and use them: blah a(hello) //assuming there's a constructor that takes a string //deletes everything when it goes out of scope So for the lightweight abstractions Stroustrup talks about, this works very well. And you'll rarely have a memory leak (only in the class itself) and no dangling pointers. And what about the grey area between lightweight and heavyweight? You say just use copy constructors and no pointers. Can you (ie C++) guarantee that no pointer is ever copied out of scope of these copy-constructed objects? For other things, though, you have to dynamically create objects. But the C++ reference-counting smart pointers offer much of the same destruction semantics as using static objects. It's really a slick system. Almost makes memory management a non-issue. Circular references will still leak (just like they do on Python). But it certainly makes life a lot more pleasant than in C from a memory management perspective. The case of RAII vs gc is hardly conclusive: http://stackoverflow.com/questions/228620/garbage-collection-in-c-why -- https://mail.python.org/mailman/listinfo/python-list
