[Python-3000] how about switching to a preprocessor? (Re: A better way to initialize PyTypeObject)
brett at python.org
Sun Dec 3 00:04:27 CET 2006
On 12/2/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
> 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);
> 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.
Assuming spam.pym is the generated C file that should be a good level of
separation and minimize the impact of the generated code in debugging
(assuming that module is not entirely object-based).
(hmm. am I reinventing SWIG here?)
=) Maybe. Depends on the level of hinting and syntax change you want from
C code compared to the pre-processed code.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-3000