> I think we have all the machinery for making extending python an easy
> job. Guido's bgen stuff (Guido, did you advertise that yet?) takes
> rather simple interface definitions as input and generates modules
> automatically for simple routines (and with a little hand-holding
> it'll also do complicated things like callback routines from C to
> python). The novice user would only have to write a set of C routines
> and explain the interfaces to bgen...
> And there's my *>MODULATOR<* stuff, of course, that takes a slightly
> different approach by giving the user complete boilerplates. But then
> they *do* have to know the internals of the python implementation,
> since they'll be on their own for arg parsing, etc.
These tools (will be and) are very very useful, but they mainly deal
with developing the interface to C modules. We need a better model
for facilitating access to Python from C.
Also, we need more documentation for the tools we have. For example,
modulator generates templates for building new types, but it does not
tell one what the semantics of the various operations are. We need
someone to write a how-to manual for building Python built-in types
that explains what the various methods do and how they interact with
the interpreter.
--
-- Jim Fulton jfulton@mailqvarsa.er.usgs.gov (703) 648-5622
U.S. Geological Survey, Reston VA 22092
This message is being posted to obtain or provide technical information
relating to my duties at the U.S. Geological Survey.