[Python-3000] how about switching to a preprocessor? (Re: A better way to initialize PyTypeObject)
ntoronto at cs.byu.edu
Sat Dec 2 22:22:58 CET 2006
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
>> 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
>> 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
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.
More information about the Python-3000