Design thought for callbacks

[Laura Creighton]

somebody, I got confused with the indent level wrote:

>> They force the use of the much slower cycle-detecting GC, rather than
>> the quick and efficient CPython refcounter.

Somebody has misunderstood something here.  When it comes to efficient
garbage collectors, refcounting is a turtle.  The CPython one is no
exception.  Ref counting, however, is fairly easy to write.  But when
the PyPy project first replaced its refcounting gc with its very first
and therefore not very efficient at all nursery gc ... that was the very
first time when a bunch of python programs ran faster on pypy than on
CPython.  This was before pypy had a JIT.

And today the pypy channel is full of people who want to link their
C extension into some Python code running on PyPy, and who find that
their C extension slows things down.  There are lots of reasons for
this, but one of the most common problems is 'this C extension is
faking refcounting.  All of this is wasted effort for PyPy and
usually makes the thing unJITable as well.'  Many of these people
rewrite their C extension as pure Python and find that then, with
PyPy, they get the speed improvements they were looking for.

So: two points.

One reason you might not want to rely on ref counting, because you expect
your code to run under PyPy one day.

and

If you are interested in manipulating garbage collection -- especially if
this is for your own pleasure and enjoyment, a worthy goal in my books --
you could do a lot worse than write your own gc in RPython for PyPy.
The gc code is not mixed in with all of the other VM stuff, so a gc is
small, and you don't have to worry about clobbering anything else while
you are working.  So it is great for experimenting, which was the whole
point.  Hacking gcs is fun! :)

Laura