[Python-3000] how about switching to a preprocessor? (Re: A better way to initialize PyTypeObject)
Fredrik Lundh
fredrik at pythonware.com
Sat Dec 2 21:34:38 CET 2006
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>
More information about the Python-3000
mailing list