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

[Brett Cannon]

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);
>      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.


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.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20061202/d809ab65/attachment.htm