[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