> Another approach would be to develop a C to Python translator.
> That would also be a large amount of work and its conceivable
> that certain features would have to be added to Python to make it
> feasible but it would allow one to translate not only the bulk of
> the curses source but many other C libraries all in one go.
An interesting idea, but I'm afraid there would be a type mismatch. C
is essentially an assembly language; Python is somewhat more abstract
and application-oriented. There are many different ways of doing
objects, error signalling, etc., in C, and you'd have to keep pointing
out what your *particular* object idiom is for it to be *correctly*
translated to Python. Similarly for exceptions; you'd have to keep
pointing out that in this program, *this* is an exception, while in
*that* program, *that* is an exception. How would malloc(), free() be
represented? I think you'd wind up with something like the output of a
disassembler.
It seems to me that the current model of constructing new Python modules
in C, like stdwin or dbm, is a reasonable solution to the problem of
using external libraries.
Bill