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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
