msg208325 - (view) |
Author: Larry Hastings (larry) *  |
Date: 2014-01-17 07:35 |
The long-awaited, highly desirable "buffer" patch is here! With features I figured would never see the light of day. Changes in this patch: * New directive "output": output redirects a "field" (subsection of Clinic's generated code) to an alternate "destination" (someplace besides the output block) predefined destinations: block buffer file two-pass suppress * Alternate use of "output": output preset redirects all destinations en mass based on a precreated scenario predefined presets: original file buffer partial-buffer two-pass * New directive "destination": destination [] creates new destinations for use with "output" valid types: buffer file two-pass suppress * New directive "dump": dump dumps the contents of a destination into the current file * New directive "preserve": preserve preserves the current output in an output block (used by "file" destinations) * New directive "set": set line_prefix set line_suffix * New output template, uses PyArg_UnpackTuple * New compact output template, for simple METH_O, only one line * "args" and "kwargs" variables in C renamed to "_args" and "_kwargs" Patch is not ready for checkin, as it still needs documentation. But it's ready for code review! There's a lot of churn in the C files. That's due to the following changes, in order of frequency: * "args" -> "_args" * "kwargs" -> "_kwargs" * new concise METH_O template * PyArg_UnpackTuple generator |
|
|
msg208334 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2014-01-17 11:53 |
Can Argument Clinic be simplified when drop support for all alternative outputs besides a side file? > * "args" and "kwargs" variables in C renamed to "_args" and "_kwargs" Why this is needed? If buildin function has "args" or "kwargs" keyword arguments, C variables can be renamed to args_value and kwargs_value, as for any reserved keywords (e.g. "default", "int"). Other changes look very good, but these are just add code churn. |
|
|
msg208355 - (view) |
Author: Larry Hastings (larry) *  |
Date: 2014-01-17 19:13 |
If I removed support for all destinations except files, I might be able to remove fifty lines or so. However, I'm not planning on doing that. Does cryptmodule.c, which has exactly one function, really need a 20-line separate file? Also, the "file" approach often requires rearranging the file before it will work, like moving struct declarations (or at least making forward declarations) before the #include of the generated file. The change of "args" to "_args" is me planning ahead a little; I plan to add the ability to get "args" and "kwargs" passed in to the impl function, both visibly to the signature, or silently (for bizarre functions like module_connect() in Modules/sqlite/connect.c). It would be possible to do this without renaming them, but then a) it would slightly complicate the approach I plan to take, and b) it would mean adding those ugly "_value" suffixes where they aren't strictly necessary. So I elected to bite the bullet and have the code churn now, in the middle of this patch that already has some code churn. However, I've been thinking about it all morning, and maybe I should just bite the bullet and make the code generator understand values whose name is different in the parsing and impl functions. (By the way, my next major patch, enabling signatures to work for all the other builtin types besides simple functions, will have lots of unavoidable code churn. You are forewarned!) |
|
|
msg208361 - (view) |
Author: Larry Hastings (larry) *  |
Date: 2014-01-17 20:58 |
I have backed out the "args" -> "_args" change. Not because I'm giving up on it, or that I necessarily think it's a bad idea, but because there are some changes happening in #20189 that will make it easier / that would conflict if I attacked it now. The resulting patch is smaller than the first iteration. And since you said it was fine except for that, I assume this patch is fine and can go in? |
|
|
msg208372 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2014-01-17 23:51 |
The patch is too large and I don't very conversant with this code, so I just left several minor comments on Rietveld. At first glance all looks good. All works with my patches, results are good. But I see that side fail names have extension .clinic.c. The .c.clinic extension would be better. For now clinic_test is failed: Error: Destination does not exist: 'file' |
|
|
msg208374 - (view) |
Author: Larry Hastings (larry) *  |
Date: 2014-01-18 00:12 |
I have a fix already in place for the clinic_test.py problem. I disagree with your proposed "foo.c.clinic" nomenclature, and there are advantages to "foo.clinic.c": double-clicking on them will launch the correct editor, and editors will automatically color them correctly. We've had this discussion before, and you weren't able to change my mind then, so please give the bikeshedding a rest. |
|
|
msg208378 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2014-01-18 01:47 |
New changeset 7f6712954d5d by Larry Hastings in branch 'default': Issue #20287: Argument Clinic's output is now configurable, allowing http://hg.python.org/cpython/rev/7f6712954d5d |
|
|
msg208379 - (view) |
Author: Larry Hastings (larry) *  |
Date: 2014-01-18 01:48 |
Done! |
|
|