Fredrik Lundh 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?) >
+10. This is the first thing that popped into my head when you brought up using a preprocessor. I've done extension modules with Pyrex, SWIG, and straight C, and the Pyrex ones are a whole heckuva lot easier to create than anything, and are generally more bug-free. One potential problem with this idea is that you can't drop into C code without calling an external C function, which may not be acceptable in some instances. Another is that if you want to analyze the performance of your code, you at least have to *look* at the C code it generates, which is a bit icky. I think that's pretty much going to happen no matter what though, unless the preprocessor is only a very thin wrapper around C. Neil _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
