Jython, GILs and object locking.

[Andrew Dalke]

Jon Franz:
> How much of guarantee do you have that this third party C library
> will continue to work with future versions of python now?

Quite a bit.  The library is the Daylight toolkit, and has been around
in one form or another for the last 15 years; the most recent form,
in C instead of Fortran, has been around for about a decade.  It's
used by some of the large pharmaceutical companies as the basis
for their chemical informatics systems, so in that regard it's a
well-entrenched legacy system.  And it was designed to be future
resistant (all data access is through functions acting on opaque
integer handles to data structures) so it can maintain backwards
compatibility and so the same library can be called from Fortran.

I maintain the interface layer, but it was developed by someone
else (Roger Critchlow) and based on SWIG.  That translation
code essentially hasn't changed in five years, and it does the
obvious thing one would do for an hand-rolled interface.

I also maintain the high-level Python interface (with full OO,
gc, iterators, etc) to the low-level module.  The gc code was
particularly tricky because I have to defined my own __del__
to get the deallocations to occur in the right order.

The developers of the toolkit use C and don't want to even
consider any other language.  The only people who would
want them to support a more flexible GC interface are wierdos
like me who prefer Python, and I don't have anywhere near
enough influence to make that drastic a change to their API.

> I'm not endorsing rewriting every C-based extension module, I'm just
> pointing it out that things change, regardless of this proposal on the
> table.

Sure.  I'm just pushing for compatibility, not denying there are
good reasons for change.

                    Andrew
                    dalke at dalkescientific.com