Queue cleanup

[Steven D'Aprano]

On Sun, 29 Aug 2010 17:52:38 -0700, Paul Rubin wrote:

>> That's a problem with the CPython API, not reference counting. The
>> problem is that the CPython API is written at too low a level, beneath
>> that at which the garbage collector exists, so naturally you have to
>> manually manage memory.
> 
> Care to give an example of a reference counted system that's written any
> other way?

The complexity of the ref counter is invisible when writing pure Python 
code, and I believe it is also invisible when writing code in Cython. The 
difficulty of dealing with ref counts is abstracted away.

The argument that "it will work if we always do this" means that it won't 
work is a nice quip, but it doesn't stand up. It's possible to defeat 
even Pascal compilers' type checking and do unsafe things by dropping 
down into assembly. So don't do it! It's not hard to not do something, 
although sometimes you might choose to do it anyway, because otherwise 
there is no way to get the code you need/want. But such code should be a 
rare exception.

I'm not saying that ref counting systems can avoid incrementing and 
decrementing the ref counts. That would be silly. But I'm saying that it 
is an accident of implementation that writing C extensions requires you 
to manually manage the counts yourself. That's a side-effect of 
permitting coders to write C extensions in pure C, rather than in some 
intermediate language which handles the ref counts for you but otherwise 
compiles like C. If people cared enough, they could (probably) make the C 
compiler handle it for them, just as it currently handles incrementing 
and decrementing the return stack. 

There's nothing *fundamental* to the idea of ref counting that says that 
you must handle the counts manually -- it depends on how well insulated 
you are from the underlying machine.



-- 
Steven