Python's biggest compromises

[Andrew Dalke]

Paul Rubin:
> I'd say the opposite, the Lisp implementations I've worked on are
> considerably easier to write C extensions for, partly BECAUSE you
> don't have to worry about constantly tweaking ref counts.

I've mentioned in c.l.py before a library I used which can be called
from both C and FORTRAN.  The latter doesn't support pointers,
so instead the library has a global instance table, indexed by integers.
The C/FORTRAN code just passes integers around.

In addition, there are dependencies between the objects, which
means that user code object deallocation can only occur in a
certain order.

With CPython it's possible to put a high-level OO interface to
that library, and provide hooks for the ref-counted gc to call
the proper deallocators in the correct order.  This is done by
telling the finalizer how to do it and paying careful attention to
order.

The library also has Java bindings.  As far as I can tell, it's
impossible to hook into Java's automatic gc.  A C-level
gc like Boehm can't ever tell that data is no longer needed,
because the global table keeps a reference to every created
object, and Java's native gc doesn't make the proper
guarantees on finalization order.

                    Andrew
                    dalke at dalkescientific.com