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

Neil Toronto ntoronto at cs.byu.edu
Sat Dec 2 21:58:56 CET 2006


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



More information about the Python-3000 mailing list