Jim Jewett added the comment: I'm not sure I correctly understand skrah's proposal. If I do, then
(1) The first several lines ( "/* pymacro.h */" until "/* could go into a separate header file */" ) would not be written at all, and are just there to help reviewers understand. (2) The "#define OS_STAT_DOC ..." line is the docstring, and would be needed, but could easily go into a separate header file, like os_stat__doc.h. For something like cdecimal, there might be only a single _cdecimal__doc.h containing all the docstrings. There might even be a build switch that (at a minimum) replaced anything from those __doc.h files with "" for space-constrained builds. (3) The human-maintained code would be the DSL between "/*[preprocessor]" and "[preprocessor]*/". (4) The lines between "[preprocessor]*/" and "/*[preprocessor end:f3e6b328245207c240825782d908d3ff3a9c11c0]*/" would NOT be written or maintained by a human, but WOULD be checked into hg for the benefit builders without the argument-clinic tool. (5) The only C code written or maintained by a human (or another macro system) would be the last 5 lines (the system call, the path cleanup, and the return). If I'm wrong about the above assumptions, then I think your proposal is insufficiently ambitious. If I'm correct, then your proposal boils down to (1) Allow (require?) the function-level docstring to be defined somewhere else, possibly in another file. (2) Change the DSL (2a) Get rid of function flags? (Not sure this is workable) (2b) Replace the (previously proposed) parameter declarations with literal C code forming an array of [parameter kind, array-of-setup-instructions-and-or-magically-named-variable-settings] More flexibility in building the docstring is probably good. The other changes -- I'm not sure I see the advantage, except that it might simplify writing the thing as a C pre-processing macro. ---------- nosy: +Jim.Jewett _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16612> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
