Article of interest: Python pros/cons for the enterprise
jeff at schwabcenter.com
Fri Feb 22 20:18:56 CET 2008
Carl Banks wrote:
> On Feb 22, 12:23 am, Jeff Schwab <j... at schwabcenter.com> wrote:
>> 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 resourcewithout bringing
>> anything of particular value to the table.s. 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.
> If you have garbage collection, the management of memory is
> consistent, and mostly automated.
>> Managing memory is
>> just not that difficult,
> Managing resources is just not that difficult,
>> especially if the vast majority of objects are
>> allocated on the stack or in static memory.
> Especially if the there are fewer resources to manage than there would
> have been heap objects....
>> A special language feature
>> for managing dynamically allocated memory robs the programmer of a
>> reliable way to clean up resources automatically,
> A special language feature more managing dynamically allocated robs
> the programmer of a reliable way to free memory automatically,
>> without bringing
>> anything of particular value to the table.
> without bringing
> anything of particular value to the table.
> It cuts both ways, chief.
> You like managing your own memory, be my guest. But please don't
> imply that you're putting forth less effort because of it. You're
> just putting forth different effort.
I disagree with you completely. Your points don't make any sense to me
at all. I believe I am putting forth less effort by having a generic
resource-management infrastructure, rather than a memory-specific
language feature -- that's not just an implication, it's my honest belief.
But I guess we'll agree to disagree.
More information about the Python-list