On 12/2/06, Barry Warsaw <[EMAIL PROTECTED]> 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.
Right, but how much generated code are we talking about here? There is filling in the type struct, ParseTuple(), and the init function. All of that is boilerplate and not hard to get right in terms of auto-generation. And it also would be easy to have it be very clean to read. I know I am personally in favour of exploring no more than the three steps listed above and not going as far as a totally new syntax ala Pyrex. We don't need a DSL just for Python extensions. I can understand this worry with something like Pyrex where you completely change the syntax, but if we keep the "magic sauce" to the function declaration line then the impact shouldn't be too bad. This is especially true with something that is only going to be a prefix chunk of code for parsing arguments to your C code for methods and the auto-generated init function. -Brett
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
