[Python-3000] how about switching to a preprocessor? (Re: A better way to initialize PyTypeObject)

[Fredrik Lundh]

Brett Cannon wrote:

> So you are basically saying you want the preprocessor step to be 
> lightweight enough that you always develop with the file before the 
> preprocessor is run instead of with some generated file, right?

exactly.  the developer should *never* edit generated data (whether 
that's a separate file fed to the compiler, an include file included by 
the original file, or auto-generated sections *inside* the original file).

> Regardless, one could take a Pyrex bent on this and having Python-like 
> method declarations but have C as the code body::

(some days, I wonder if we shouldn't just include Pyrex and tell every- 
one to use that for *all* their extension work.  Greg?  how much work 
would it be to equip Pyrex with a "retargetable" backend?)

:::

but back to the preprocessor; I think it might be possible to limit its 
impact on the C source file to a single #include statement at the end of 
the file, which includes the generated code.  to provide hints for the 
preprocessor, Python.h would provide a bunch of C macros that are parsed 
by the module preprocessor, but (mostly) ignored by the C compiler.

the spam module from the extension manual could then look something like

#include "Python.h"

static PyObject *SpamError;

PYM_FUNCTION(spam)(char* command)
{
     int sts;
     sts = system(command);
     return Py_BuildValue("i", sts);
}

PYM_INIT(PyObject* module)
{
     SpamError = PyErr_NewException("spam.error", NULL, NULL);
     Py_INCREF(SpamError);
     PyModule_AddObject(module, "error", SpamError);
}

#include "spam.pym"

and the preprocessor would then generate the necessary trampolines and 
tables, and of course the public initspam function.  extending this to 
deal with optional arguments, methods, and perhaps even return values is 
mostly trivial.

(hmm.  am I reinventing SWIG here?)

more later.

</F>