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

[Neil Toronto]

Barry Warsaw wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Dec 2, 2006, at 3:58 PM, Neil Toronto wrote:
>
>   
>> 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.
>>     
>
> We need to keep in mind things like debugging and code discovery  
> (IDE, tags, grep), when talking about requiring the use of a  
> preprocessor for extensions.  For an application like ours that is  
> very heavily embedded/extended I'm concerned how difficult it will be  
> debug, develop, and maintain these generated extensions.  Generated  
> code can be a big time saver while you'r developing the code, but  
> eventually you have to go digging into it, then it's always way more  
> painful.
>   

Yeah, I've had to dig into my generated code a couple of times to 
determine why certain string operations weren't working.

As far as maintaining goes, though, I regard the C code as temporary - 
kind of like high-level object code. I wouldn't *want* to maintain it in 
my most heinous nightmares. This has already been mentioned twice, but 
whatever the solution is, a developer should never have to do that.

A debugger that could step over Pyrex code would be wicked cool. Second 
to that would be Pyrex-generated code that didn't make your eyes bleed. 
(No offense intended, Greg. :D) That should be fairly possible.

Neil