Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Carl Banks wrote:
> On Feb 21, 7:17 pm, Jeff Schwab <j... at schwabcenter.com> wrote:
>> Carl Banks wrote:
>>> On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa... at gmail.com> wrote:
>>>> There are other downsides to garbage collection, as the fact that it
>>>> makes it harder to implement the Resource Acquisition Is
>>>> Initialization idiom, due to the lack of deterministic destruction.
>>> That's not a downside: it's at least a wash.
>>> In C++ you manage memory and the language manages resources.  In
>>> Python you manage resources and the language manages memory.
>>> RAII is merely one way of minimizing complexity.  Garbage collection
>>> is another way.
>> If you've already got a generic, language-supported way to manage
>> resources (like RAII with deterministic destruction), then why bother
>> with garbage collection?
> 
> Because now you have to manage memory?  Did you read my post?  You
> have to manage one thing or the other.

Yes, I read your post.  You seem to be saying there's some kind of 
trade-off between automatic management of dynamically allocated memory, 
and automated management of other kinds of resources.  I don't 
understand why you believe that, so I asked.

If you have proper RAII and deterministic destruction, the management is 
of resources is consistent, and mostly automated.  Managing memory is 
just not that difficult, especially if the vast majority of objects are 
allocated on the stack or in static memory.  A special language feature 
for managing dynamically allocated memory robs the programmer of a 
reliable way to clean up resources automatically, without bringing 
anything of particular value to the table.


>> I'm not trying to knock it; it was a big step
>> up from C-style "who forgot to delete a pointer" games.  It just seems
>> to me like a solution to something that's no longer a problem, at least
>> in well-written C++ code.  I'll take destructors over GC any day.
> 
> About 2% of the objects I creat have resources other than memory.  I
> would rather manage resources of 2% of objects than manage memory of
> 100%.

That's not how it works.  If I'm going to allocated a C++ object 
dynamically, I have to assign it to some kind of handle, anyway, so I 
might as well just use a smart pointer that will delete the object when 
there are no more references to it.  There is no extra effort involved.

The most traditional, easiest way to open a file in C++ is to use an 
fstream object, so the file is guaranteed to be closed when the fstream 
goes out of scope.  CPython offers a similar feature, since you can 
create a temporary object whose reference count will become zero at the 
end of the statement where it is defined:

     $ echo world >hello
     $ python
     >>> file('hello').read()
     'world\n'

It's graceful, easy to write, and a million times better than having to 
clean up the resource explicitly.  A book on Python I was reading 
recently (either Alex Martelli or Mark Lutz) used this idiom again and 
again, and every time had to have a footnote about how it wouldn't work 
right on (e.g.) JPython, because who knows if/when the resource-owning 
object's finalizer will ever get called.

Admittedly, you have to know enough to use the right kinds of objects, 
but that's something you have to learn anyway.


> YMMV, but I suspect mine is the more common opinion, if the
> recent (like, 10-year) trend in programming languages is any
> indication.

I agree that support for non-deterministic GC has grown very popular 
over the past ten years or so.  I don't think that is evidence of it 
being a good idea though; I suspect that opinion of being the product of 
widespread ignorance about alternatives to unpredictable GC.