<br><br><div><span class="gmail_quote">On 12/2/06, <b class="gmail_sendername">Fredrik Lundh</b> <<a href="mailto:fredrik@pythonware.com">fredrik@pythonware.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Brett Cannon wrote:<br><br>> So you are basically saying you want the preprocessor step to be<br>> lightweight enough that you always develop with the file before the<br>> preprocessor is run instead of with some generated file, right?
<br><br>exactly. the developer should *never* edit generated data (whether<br>that's a separate file fed to the compiler, an include file included by<br>the original file, or auto-generated sections *inside* the original file).
<br><br>> Regardless, one could take a Pyrex bent on this and having Python-like<br>> method declarations but have C as the code body::<br><br>(some days, I wonder if we shouldn't just include Pyrex and tell every-<br>
one to use that for *all* their extension work. Greg? how much work<br>would it be to equip Pyrex with a "retargetable" backend?)<br><br>:::<br><br>but back to the preprocessor; I think it might be possible to limit its
<br>impact on the C source file to a single #include statement at the end of<br>the file, which includes the generated code. to provide hints for the<br>preprocessor, Python.h would provide a bunch of C macros that are parsed
<br>by the module preprocessor, but (mostly) ignored by the C compiler.</blockquote><div><br>> the spam module from the extension manual could then look something like<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>#include "Python.h"<br><br>static PyObject *SpamError;<br><br>PYM_FUNCTION(spam)(char* command)<br>{<br> int sts;<br> sts = system(command);<br> return Py_BuildValue("i", sts);<br>}<br>
<br>PYM_INIT(PyObject* module)<br>{<br> SpamError = PyErr_NewException("spam.error", NULL, NULL);<br> Py_INCREF(SpamError);<br> PyModule_AddObject(module, "error", SpamError);<br>}<br><br>#include "
spam.pym"<br><br>and the preprocessor would then generate the necessary trampolines and<br>tables, and of course the public initspam function. extending this to<br>deal with optional arguments, methods, and perhaps even return values is
<br>mostly trivial.</blockquote><div><br>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).
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">(hmm. am I reinventing SWIG here?)</blockquote><div><br>=) Maybe. Depends on the level of hinting and syntax change you want from C code compared to the pre-processed code.
<br></div><br>-Brett<br></div>