Hello, Several core developers a bit unhappy with the way Argument Clinic currently scatters generated code into hand-written C modules. The opinion is that it makes C files more confusing and annoying to navigate through. Several solutions have been proposed: - move all generated code to separate C files, which would then be #included'd into the main module file - gather all generated code to a single place in the C module file, for example near the end (Larry's "accumulator" idea) - prefix all Clinic-generated lines with a recognizable marker, e.g. "/* AC */" What do you think? Regards Antoine.
On Tue, Jan 7, 2014, at 11:53 AM, Antoine Pitrou wrote:
Hello,
Several core developers a bit unhappy with the way Argument Clinic currently scatters generated code into hand-written C modules. The opinion is that it makes C files more confusing and annoying to navigate through.
Several solutions have been proposed: - move all generated code to separate C files, which would then be #included'd into the main module file
+1 I believe this is the "standard" solution for code generation. For example, Qt's moc uses it.
On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
Hello,
Several core developers a bit unhappy with the way Argument Clinic currently scatters generated code into hand-written C modules. The opinion is that it makes C files more confusing and annoying to navigate through.
Several solutions have been proposed: - move all generated code to separate C files, which would then be #included'd into the main module file
- gather all generated code to a single place in the C module file, for example near the end (Larry's "accumulator" idea)
- prefix all Clinic-generated lines with a recognizable marker, e.g. "/* AC */"
What do you think?
For what it's worth, I don't have a strong opinion about it. I had the first one (separate files) working at one point, as as memory serves Guido he didn't like that approach and I should remove the feature. I'm happy for Argument Clinic to do any/all/none of the above. //arry/
On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
- move all generated code to separate C files, which would then be #included'd into the main module file
-1 (Guido has stated a strong dislike for this method)
- gather all generated code to a single place in the C module file, for example near the end (Larry's "accumulator" idea)
+1
- prefix all Clinic-generated lines with a recognizable marker, e.g. "/* AC */"
+0 -- ~Ethan~
On Tue, 07 Jan 2014 12:03:00 -0800 Ethan Furman <ethan@stoneleaf.us> wrote:
On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
- move all generated code to separate C files, which would then be #included'd into the main module file
-1 (Guido has stated a strong dislike for this method)
Is it your own opinion too? Otherwise it shouldn't count as a -1.
On 01/07/2014 12:07 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:03:00 -0800 Ethan Furman <ethan@stoneleaf.us> wrote:
On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
- move all generated code to separate C files, which would then be #included'd into the main module file
-1 (Guido has stated a strong dislike for this method)
Is it your own opinion too? Otherwise it shouldn't count as a -1.
Yes it is. -- ~Ethan~
On Tue, 07 Jan 2014 12:33:11 -0800 Ethan Furman <ethan@stoneleaf.us> wrote:
On 01/07/2014 12:07 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:03:00 -0800 Ethan Furman <ethan@stoneleaf.us> wrote:
On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
- move all generated code to separate C files, which would then be #included'd into the main module file
-1 (Guido has stated a strong dislike for this method)
Is it your own opinion too? Otherwise it shouldn't count as a -1.
Yes it is.
Would you care to elaborate on why you're against it? Regards Antoine.
On 01/07/2014 01:04 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:33:11 -0800 Ethan Furman <ethan@stoneleaf.us> wrote:
On 01/07/2014 12:07 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:03:00 -0800 Ethan Furman <ethan@stoneleaf.us> wrote:
On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
- move all generated code to separate C files, which would then be #included'd into the main module file
-1 (Guido has stated a strong dislike for this method)
Is it your own opinion too? Otherwise it shouldn't count as a -1.
Yes it is.
Would you care to elaborate on why you're against it?
Seriously? Are you going to now ask all the other respondents who didn't explain themselves to do so? I don't care for it because I like to have all the code be in one file. I will say that Serhiy's comment about code churn has given me some pause to think... Okay, changing my vote to: - Use both /* AC */ markers for every line *and* have all the code be in one spot +1 This way the diffs will easily be clear on what was code generator and what was human. (Thanks, Breamoreboy, for the idea! ;) -- ~Ethan~
On Jan 07, 2014, at 08:53 PM, Antoine Pitrou wrote:
- move all generated code to separate C files, which would then be #included'd into the main module file
I'm not a big fan of this approach either, but maybe not as vehemently, so -0.
- gather all generated code to a single place in the C module file, for example near the end (Larry's "accumulator" idea)
+1
- prefix all Clinic-generated lines with a recognizable marker, e.g. "/* AC */"
+0 -Barry
07.01.14 21:53, Antoine Pitrou написав(ла):
Several core developers a bit unhappy with the way Argument Clinic currently scatters generated code into hand-written C modules. The opinion is that it makes C files more confusing and annoying to navigate through.
Several solutions have been proposed: - move all generated code to separate C files, which would then be #included'd into the main module file
Only this option will solve all my issues. My arguments against current behavior: * It increases the number of lines of code. now with Argument Clinic 1770 2704 Modules/audioop.c 1572 1997 Modules/binascii.c 3772 4558 Modules/_elementtree.c 2712 3360 Modules/_sre.c 3060 3742 Modules/_tkinter.c More PageUp/PageDown needed to list the sources, and you should be more accurate wish positioning the scrollbar. * It adds a lot of names which clutter up lists for navigation in your editor/IDE. For example if now there is only one name for the a2b_uu function in navigation list, with Argument Clinic there are three names: BINASCII_A2B_UU_METHODDEF, binascii_a2b_uu, and binascii_a2b_uu_impl (and only the last is interested for humans). If now the list of names fits in one screen, with Argument Clinic it will need three screens. * It makes harder to use search for navigation. Now a2b_uu is occurred in the source file 6 times, and with Argument Clinic it will be occurred 13 times (however moving generated code to separate file will decrease this number to 3). * It mixes manually written code with generated boilerplate * It clutters up hg log and hg blame results. Every time when you change clinic.py to generate different output, it touches multiple lines in all files which use Argument Clinic and clutters up their history. * It makes the code more errorprone. Peoples can edit generated code instead of clinic declaration. I have converted enough code to Argument Clinic last days and I seen how peoples work with already converted code, so I known what I say. If this doesn't convince you, I don't know what I can add.
On 01/07/2014 12:39 PM, Serhiy Storchaka wrote:
07.01.14 21:53, Antoine Pitrou написав(ла):
- move all generated code to separate C files, which would then be #included'd into the main module file
Only this option will solve all my issues.
My arguments against current behavior:
[snip]
* It clutters up hg log and hg blame results. Every time when you change clinic.py to generate different output, it touches multiple lines in all files which use Argument Clinic and clutters up their history.
I think this is the reason to focus on -- the others seem like editor issues, or easily resolved by the second or third options. -- ~Ethan~
On 01/07/2014 12:51 PM, Ethan Furman wrote:
On 01/07/2014 12:39 PM, Serhiy Storchaka wrote:
* It clutters up hg log and hg blame results. Every time when you change clinic.py to generate different output, it touches multiple lines in all files which use Argument Clinic and clutters up their history.
I think this is the reason to focus on -- the others seem like editor issues, or easily resolved by the second or third options.
I don't think this is a particularly compelling reason. Once things settle down, I'm not anticipating the clinic.py code generator will change very often. //arry/
07.01.14 22:51, Ethan Furman написав(ла):
On 01/07/2014 12:39 PM, Serhiy Storchaka wrote:
* It clutters up hg log and hg blame results. Every time when you change clinic.py to generate different output, it touches multiple lines in all files which use Argument Clinic and clutters up their history.
I think this is the reason to focus on -- the others seem like editor issues, or easily resolved by the second or third options.
AFAIK you don't write much C code. So perhaps C sources maintainability is not too valuable for you.
On 01/09/2014 03:39 AM, Serhiy Storchaka wrote:
07.01.14 22:51, Ethan Furman написав(ла):
AFAIK you don't write much C code. So perhaps C sources maintainability is not too valuable for you.
I don't write much C code yet, no, but C source maintainability is even more important to me because of it. Having to search several files for something makes it more difficult for me to find what I need. I have the same issues with Python code, too. Back in my windows days I had some custom functions to make py code browsing much nicer in Vim; then I changed jobs, forgot to grab the code, and now my py files are unfolded and large. So far just searching for what I'm looking for has worked well enough that I haven't reimplemented my lost functions. But that is an editor issue, not a file issue. -- ~Ethan~
On Jan 07, 2014, at 10:39 PM, Serhiy Storchaka wrote:
Only this option will solve all my issues.
How hard would it be to put together some sample branches that provide concrete examples of the various options? My own opinion could easily be influenced by having some hands-on time with actual code, and I suspect even Guido could be influenced if he could pull some things up in his editor and take a look around. -Barry
On 01/08/2014 07:08 AM, Barry Warsaw wrote:
On Jan 07, 2014, at 10:39 PM, Serhiy Storchaka wrote:
Only this option will solve all my issues. How hard would it be to put together some sample branches that provide concrete examples of the various options?
My own opinion could easily be influenced by having some hands-on time with actual code, and I suspect even Guido could be influenced if he could pull some things up in his editor and take a look around.
I plan to prototype the "accumulator" later today. It probably wouldn't be hard to make the prototype support writing out to a separate file, so I'll try to do that too. //arry/
On 01/08/2014 07:08 AM, Barry Warsaw wrote:
How hard would it be to put together some sample branches that provide concrete examples of the various options?
My own opinion could easily be influenced by having some hands-on time with actual code, and I suspect even Guido could be influenced if he could pull some things up in his editor and take a look around.
I've uploaded a prototype here: https://bitbucket.org/larry/python-clinic-buffer It's a clone of Python trunk, so if you already have a trunk handy, clone that first then "hg pull -u" from the above and it'll go a lot quicker. The prototype adds some commands to Argument Clinic that allow you to specify where each bit of its output goes. You have four choices: * You can write to the output block as before. * You can buffer up the text for writing out later in the same file. * You can write to a file on the side. * Or you can throw it away. To learn how to run your own experiments, read "CLINIC.BUFFER.NOTES.TXT" in the root of the repository. For your tl;dr pleasure I've included recipes for the proposed approaches so far. I don't propose to check in the prototype in its current state. But it should be sufficient for running everybody's experiments. (If there's something you want to try that my prototype doesn't support, contact me and I should be able to throw in a feature for you.) Happy experimenting, //arry/
On 01/11/2014 07:35 PM, Larry Hastings wrote:
On 01/08/2014 07:08 AM, Barry Warsaw wrote:
How hard would it be to put together some sample branches that provide concrete examples of the various options?
My own opinion could easily be influenced by having some hands-on time with actual code, and I suspect even Guido could be influenced if he could pull some things up in his editor and take a look around.
I've uploaded a prototype here:
I have now received exactly zero feedback about the prototype, which suggests people aren't using it. In an attempt to jump-start this conversation, I've created a new repository containing the "concrete examples of the various options" that Barry proposed above. You may find it here: https://bitbucket.org/larry/clinic-buffer-samples/src In it I converted Modules/_pickle.c four different ways. There's a README, please read it. People who want to change how Clinic writes its output: this is your big chance. Comment on these samples, or produce your own counterexamples, or something. If you can enough people on your side maybe Clinic will change. If there is no further debate on this topic, nothing will happen and Clinic will not change. //arry/
On Tue, Jan 14, 2014 at 2:22 PM, Larry Hastings <larry@hastings.org> wrote:
I have now received exactly zero feedback about the prototype, which suggests people aren't using it.
Oops, I had half a post written about this two days ago, but never got it posted. I did some experimenting on winreg.c (see http://hg.python.org/sandbox/zware/file/prototype_clinic/PC/winreg.c), and I have to say I really really like having most of the output shunted down to the bottom of the file. In that example I have only the implementation outputting to the block, and everything else (that's necessary) going into the buffer; to me it looks very nice and clean. One of my biggest annoyances with the current output is having the docstring repeated nearly verbatim (with additives) within just a few lines, and this takes care of that and more. To me, those converted functions read about as close to real Python as is ever going to happen in a C file. One thing that I could see being useful (though possibly not easy) is the ability to dump a buffer "late"; for example, near the top of the file: /*[clinic input] destination prototypes new buffer output parser_prototype prototypes dump prototypes later [clinic start generated code]*/ Then process the file, filling the prototypes buffer as we go. At the end of the file, go back and dump the buffer in that output block. I like the flexibility of the prototype, having more control over what goes where is always nice :) -- Zach
On 01/14/2014 12:48 PM, Zachary Ware wrote:
On Tue, Jan 14, 2014 at 2:22 PM, Larry Hastings <larry@hastings.org> wrote:
I have now received exactly zero feedback about the prototype, which suggests people aren't using it. Oops, I had half a post written about this two days ago, but never got it posted.
I did some experimenting on winreg.c (see http://hg.python.org/sandbox/zware/file/prototype_clinic/PC/winreg.c), and I have to say I really really like having most of the output shunted down to the bottom of the file.
I will consider you a +1 on the "buffer" approach and NaN on the other approaches.
One thing that I could see being useful (though possibly not easy) is the ability to dump a buffer "late"; for example, near the top of the file:
/*[clinic input] destination prototypes new buffer output parser_prototype prototypes dump prototypes later [clinic start generated code]*/
Then process the file, filling the prototypes buffer as we go. At the end of the file, go back and dump the buffer in that output block.
That wouldn't be too hard. But conceptually it would make Clinic much more complicated. For example, I suggest that "later" is a confusing name, because the output will actually happen *earlier* in the file. "If it's hard to explain, it may be a bad idea." ;-) //arry/
On Tue, Jan 14, 2014 at 2:54 PM, Larry Hastings <larry@hastings.org> wrote:
I will consider you a +1 on the "buffer" approach and NaN on the other approaches.
Oops, I'll give you some real numbers: -1 _pickle.original.c +1 _pickle.using-buffer.c +0 _pickle.using-modified-buffer.c +1 _pickle.using-multiple-buffers.c +0 _pickle.using-sidefile.c
That wouldn't be too hard. But conceptually it would make Clinic much more complicated. For example, I suggest that "later" is a confusing name, because the output will actually happen *earlier* in the file. "If it's hard to explain, it may be a bad idea." ;-)
Fair enough :). "later" makes sense to me as "there's nothing in the buffer now, but there will be later; dump it here then". The spark for this idea is in _winapi.c, where OverlappedObject's methoddef is actually before any of the methods are implemented which makes a certain amount of sense as a list of what will be implemented; but as far as I can tell, it isn't possible to replicate this with Clinic right now. Having read the readme in your examples, this could also help with the chicken-and-egg problem you talked about using the various buffers: dump docstrings at the top, followed by prototypes, then methoddef defines near where they're needed (or even perhaps output them directly into the PyMethodDef structure, no defines needed). -- Zach
On 01/14/2014 12:22 PM, Larry Hastings wrote:
I have now received exactly zero feedback about the prototype, which suggests people aren't using it. In an attempt to jump-start this conversation, I've created a new repository containing the "concrete examples of the various options" that Barry proposed above. You may find it here:
https://bitbucket.org/larry/clinic-buffer-samples/src
In it I converted Modules/_pickle.c four different ways. There's a README, please read it.
People who want to change how Clinic writes its output: this is your big chance. Comment on these samples, or produce your own counterexamples, or something. If you can enough people on your side maybe Clinic will change. If there is no further debate on this topic, nothing will happen and Clinic will not change.
I checked the README, the current file, and the buffered files. My preferences from highest to lowest: - modified buffer approach - buffer approach - side file Thanks for taking the time, Larry! -- ~Ethan~
On 01/14/2014 12:51 PM, Ethan Furman wrote:
I checked the README, the current file, and the buffered files. My preferences from highest to lowest:
- modified buffer approach - buffer approach - side file
Could you put that in the form of numbers from +1 to -1? I'm literally making a spreadsheet to tally people's votes.
Thanks for taking the time, Larry!
Thanks for participating in this sham democracy! ;-) //arry/
On 01/14/2014 02:28 PM, Larry Hastings wrote:
On 01/14/2014 12:51 PM, Ethan Furman wrote:
I checked the README, the current file, and the buffered files. My preferences from highest to lowest:
+1 modified buffer approach +0.5 buffer approach +0 side file
NaN on the others is fine. ;) -- ~Ethan~
On Tue, Jan 14, 2014 at 3:22 PM, Larry Hastings <larry@hastings.org> wrote:
On 01/11/2014 07:35 PM, Larry Hastings wrote:
On 01/08/2014 07:08 AM, Barry Warsaw wrote:
How hard would it be to put together some sample branches that provide concrete examples of the various options?
My own opinion could easily be influenced by having some hands-on time with actual code, and I suspect even Guido could be influenced if he could pull some things up in his editor and take a look around.
I've uploaded a prototype here:
https://bitbucket.org/larry/python-clinic-buffer
I have now received exactly zero feedback about the prototype, which suggests people aren't using it. In an attempt to jump-start this conversation, I've created a new repository containing the "concrete examples of the various options" that Barry proposed above. You may find it here:
https://bitbucket.org/larry/clinic-buffer-samples/src
In it I converted Modules/_pickle.c four different ways. There's a README, please read it.
People who want to change how Clinic writes its output: this is your big chance. Comment on these samples, or produce your own counterexamples, or something. If you can enough people on your side maybe Clinic will change. If there is no further debate on this topic, nothing will happen and Clinic will not change.
+0 _pickle.original.c +1 _pickle.using-buffer.c -0 _pickle.using-modified-buffer.c +1 _pickle.using-multiple-buffers.c -0 _pickle.using-sidefile.c
On Tue, 14 Jan 2014 12:22:12 -0800 Larry Hastings <larry@hastings.org> wrote:
https://bitbucket.org/larry/clinic-buffer-samples/src
In it I converted Modules/_pickle.c four different ways. There's a README, please read it.
I'm +1 on the sidefile approach. +0 on the various buffer approaches. -0.5 on the current "sprinkled everywhere" approach. Regards Antoine.
On Jan 14, 2014, at 9:12 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
I'm +1 on the sidefile approach. +0 on the various buffer approaches. -0.5 on the current "sprinkled everywhere" approach.
I concur with Antoine except that I'm a full -1 on commingling generated code with hand edited code. Sprinked everywhere interferes with my ability to grok the code. It interferes with code navigation. And it creates a greater risk of accidentally editing the generated code. FWIW, I think everyone should place a lot of weight on Serhiy's comments and suggestions. His reasoning is clear and compelling. And the thoughts are all soundly based on extensive experience with the clinic's effect on the C source code. Raymond
On 01/14/2014 01:38 PM, Raymond Hettinger wrote:
On Jan 14, 2014, at 9:12 PM, Antoine Pitrou <solipsis@pitrou.net <mailto:solipsis@pitrou.net>> wrote:
I'm +1 on the sidefile approach. +0 on the various buffer approaches. -0.5 on the current "sprinkled everywhere" approach.
I concur with Antoine except that I'm a full -1 on commingling generated code with hand edited code. Sprinked everywhere interferes with my ability to grok the code. It interferes with code navigation. And it creates a greater risk of accidentally editing the generated code.
FWIW, I think everyone should place a lot of weight on Serhiy's comments and suggestions. His reasoning is clear and compelling. And the thoughts are all soundly based on extensive experience with the clinic's effect on the C source code.
For the record I don't much care which of these Clinic does. My hope is just that the Python core dev community accepts Argument Clinic. If it forms a consensus around changing Clinic's output I'd be happy to oblige. But there's one important caveat to the above. As I recall, Guido has stated that he hates storing generated code in separate files. He has yet to rescind or weaken that pronouncement. Until such time as he does, the "side file" approach is off the table. I implemented it in the prototype purely for the purpose of fostering debate, so the "side file" proponents can try to convince him that it's necessary or that it's not so bad. But it's not going in without Guido's approval. As you yourself say--"Python is Guido's language, he just lets us use it." I'm not the person you have to convince, //arry/
15.01.14 00:24, Larry Hastings написав(ла):
But there's one important caveat to the above. As I recall, Guido has stated that he hates storing generated code in separate files. He has yet to rescind or weaken that pronouncement. Until such time as he does, the "side file" approach is off the table. I implemented it in the prototype purely for the purpose of fostering debate, so the "side file" proponents can try to convince him that it's necessary or that it's not so bad. But it's not going in without Guido's approval. As you yourself say--"Python is Guido's language, he just lets us use it."
Yes, we know. The conviction of Guido is the purpose of this topic. I hope that his silence is a good sign. Perhaps he doubts and weighs arguments. Personally, I believe that if we don't change Argument Clinic output now, we will have to do it in 3.5 or 4.0, when many people work with the code, but at the cost of history cluttering, what I want to avoid.
14.01.14 23:38, Raymond Hettinger написав(ла):
On Jan 14, 2014, at 9:12 PM, Antoine Pitrou <solipsis@pitrou.net <mailto:solipsis@pitrou.net>> wrote:
I'm +1 on the sidefile approach. +0 on the various buffer approaches. -0.5 on the current "sprinkled everywhere" approach.
I concur with Antoine except that I'm a full -1 on commingling generated code with hand edited code. Sprinked everywhere interferes with my ability to grok the code. It interferes with code navigation. And it creates a greater risk of accidentally editing the generated code.
As expected I'm same as Raymond. +1 on the sidefile approach, -1 on the current "sprinkled everywhere" approach, and about 0 on the various buffer approaches. Yet one nitpick. I prefer to have a sidefile with some unique suffix (e.g. .clinic) at the end of file name rather than in the middle. _pickle.c.clinic is better then _pickle.clinic.c (even .c in middle is not needed, it can be _pickle.clinic). My reasons: 1. I very very often use global search in sources. It's my way of navigation and it's my way of investigations. I don't want to get false results in generated files. And it is much easy to specify mask '*.[ch]' or '*.c,*.h' (depending on tool) than specify a mask and negative mask. The latter is even not always possible, I can write cumbersome expression for the find command, but Midnight Commander doesn't support negative masks at all (and perhaps your favorite IDE doesn't support them too). 2. I'm not use any IDE, but if you use, it can be important for you. If IDE shows sources tree, unlikely you want to see generated *.clinic.c files in them. This will increase the list of sources almost twice. 3. Pathname expansion works better with unique endings, You can open all Modules/_io/*.c files, but unlikely you so interested in *.clinic.c files which are matched by former pattern.
Even though I’m not a core dev, I happen to work with cpython source code quite a lot, whether it’s me working on a C extension, or just digging it for some obscure details of how python works. And what I want to say is that cpython sources are great. They are easy to understand even for people who don’t know C. What’s even more important, they are easy to navigate them. Having clinic- produced code here and there will surely complicate this. Of course, if you work with cpython code 24/7, you will adapt, and won’t even notice it, but for occasional users like me it will require more focus. For my use pattern, having clinic to produce a separate file (with a distinct extension like “.c.clinic”) would be a huge win. Besides just clean source files, it will also make it easier to: - review patches; - work with repository: logs, blames, diffs, etc; - adjusting workflow - in sublime text / eclipse / almost any IDE it would be just a file mask to hide the clinic output completely (and you don’t need to see it anyways). And besides just cpython, as I understand, the clinic should be used not just by cpython core devs for cpython sources, but also by numerous authors of C extensions. So my vote is: +1 for side files 0 for the current state of things -1 for buffers (as it makes no sense to me why would you want to have generated code at almost random places) Thanks, Yury
On 01/14/2014 01:38 PM, Raymond Hettinger wrote:
FWIW, I think everyone should place a lot of weight on Serhiy's comments and suggestions. His reasoning is clear and compelling. And the thoughts are all soundly based on extensive experience with the clinic's effect on the C source code.
One more bit of anecdotal evidence. I suggest that I have easily the most extensive experience with working with Clinic. Serhiy filed his first patch converting to Clinic nine days ago; I've been working on Clinic for about eighteen months, on and off. And I got used to living with the "sprinkling" approach a long long time ago. I no longer ever mistake generated code for handwritten code, and I don't ever modify the generated text. It's basically fine. This is not to dismiss Serhiy's observations. Nor to say that my experiences will be universal. Nor indeed to suggest that learning to live with Clinic's out as it exists today is a desirable skill. I merely suggest that if we didn't modify the output of Clinic it might be survivable. Cheers, //arry/ p.s. " You get used to it. I...I don't even see the code. All I see is blonde, brunette, red-head. Hey, you uh... want a drink?"
15.01.14 00:47, Larry Hastings написав(ла):
I also can not change the text, but twice I was a witness as others did. And I see that make this mistake very easily.
I also didn't modify the generated text, but twice I was a witness as others did. And I see that make this mistake very easily.
On 01/15/2014 01:59 AM, Serhiy Storchaka wrote:
15.01.14 00:47, Larry Hastings написав(ла):
I also can not change the text, but twice I was a witness as others did. And I see that make this mistake very easily.
I also didn't modify the generated text, but twice I was a witness as others did. And I see that make this mistake very easily.
That isn't what I wrote...? //arry/
15.01.14 17:37, Larry Hastings написав(ла):
On 01/15/2014 01:59 AM, Serhiy Storchaka wrote:
15.01.14 00:47, Larry Hastings написав(ла):
I also can not change the text, but twice I was a witness as others did. And I see that make this mistake very easily.
I also didn't modify the generated text, but twice I was a witness as others did. And I see that make this mistake very easily.
That isn't what I wrote...?
Gotcha! How I got this? I wanted to quote:
I no longer ever mistake generated code for handwritten code, and I don't ever modify the generated text.
On Tue, Jan 14, 2014 at 3:12 PM, Antoine Pitrou <solipsis@pitrou.net> wrote: On Tue, 14 Jan 2014 12:22:12 -0800
Larry Hastings <larry@hastings.org> wrote:
https://bitbucket.org/larry/clinic-buffer-samples/src
In it I converted Modules/_pickle.c four different ways. There's a README, please read it.
I'm +1 on the sidefile approach. +0 on the various buffer approaches. -0.5 on the current "sprinkled everywhere" approach.
After converting a few modules, I feel about the same. The sprinkling does clutter the file. Although, I do wonder if we can simplify things a bit for the "sideline" file by using macros and headers. You could write the original definition like: /*[clinic input begin] _pickle.PicklerMemoProxy.copy self: PicklerMemoProxyObject Copy the memo to a new object. [clinic input end]*/ static PyObject * _PICKLE_PICKLERMEMOPROXY_COPY(PyObject *self, PyObject *Py_UNUSED(ignored)) { ... } and then generate a header like: PyDoc_STRVAR(_pickle_PicklerMemoProxy_copy__doc__, "copy()\n" "Copy the memo to a new object."); #define _PICKLE_PICKLERMEMOPROXY_COPY_METHODDEF \ {"copy", (PyCFunction)_pickle_PicklerMemoProxy_copy, METH_NOARGS, _pickle_PicklerMemoProxy_copy__doc__}, static PyObject * _pickle_PicklerMemoProxy_copy_impl(PicklerMemoProxyObject *self); #define _PICKLE_PICKLERMEMOPROXY_COPY(a, b) \ _pickle_PicklerMemoProxy_copy(PyObject *self, PyObject *Py_UNUSED(ignored)) \ { \ PyObject *return_value = NULL; \ \ return_value = _pickle_PicklerMemoProxy_copy_impl((PicklerMemoProxyObject *)self); \ \ return return_value; \ } \ \ static PyObject * \ _pickle_PicklerMemoProxy_copy_impl(PicklerMemoProxyObject *self) \ This way the docstring, method def, and argument parsing code is out of the way, but you still retain the helpful comments in the implementation file. I am pretty sure this gets around the "where do I inject the side file part" too. You also don't have to do much more editing than the original scheme: write the clinic comment, #iinclude a header, and then apply the macro. That being said, this is somewhat half baked and some folks don't like macros. I just wanted to throw it out there since it seems like a reasonable compromise. FWIW, I have worked on several large programs that generate C header and implementation files on the side and it has never bothered me that much. Well, unless, something goes wrong :-) -- # Meador
Am 14.01.2014 21:22, schrieb Larry Hastings:
On 01/11/2014 07:35 PM, Larry Hastings wrote:
On 01/08/2014 07:08 AM, Barry Warsaw wrote:
How hard would it be to put together some sample branches that provide concrete examples of the various options?
My own opinion could easily be influenced by having some hands-on time with actual code, and I suspect even Guido could be influenced if he could pull some things up in his editor and take a look around.
I've uploaded a prototype here:
I have now received exactly zero feedback about the prototype, which suggests people aren't using it. In an attempt to jump-start this conversation, I've created a new repository containing the "concrete examples of the various options" that Barry proposed above. You may find it here:
https://bitbucket.org/larry/clinic-buffer-samples/src
In it I converted Modules/_pickle.c four different ways. There's a README, please read it.
People who want to change how Clinic writes its output: this is your big chance. Comment on these samples, or produce your own counterexamples, or something. If you can enough people on your side maybe Clinic will change. If there is no further debate on this topic, nothing will happen and Clinic will not change.
Having converted several modules to AC, I think I'm -1 original +0 sidefile +1 multiple buffers +0 buffer -0 modified buffer Georg
I favor a dual-mode approach. I think the existing behavior is best for the conversion of existing modules, because it's easy to interactively verify the generated code. Once that's done, long-term maintenance definitely favors a more centralized format. +1 _pickle.original.c /* used only during conversion of existing modules */ +0 _pickle.using-buffer.c +1 _pickle.using-modified-buffer.c -1 _pickle.using-multiple-buffers.c NaN _pickle.using-sidefile.c /* not enough experience with it */ Pondering it this afternoon, I thought of a configuration that minimizes both code churn and readability impact: two buffers. One at the top containing forward declarations and defines (an inline header file if you like), and the rest of the autogenerated code at the bottom. It's not obvious that AC currently supports this configuration, or backtracking of any kind. Nonetheless: +1 _pickle.using-two-buffers.c On Tue, Jan 14, 2014 at 12:22 PM, Larry Hastings <larry@hastings.org> wrote:
On 01/11/2014 07:35 PM, Larry Hastings wrote:
On 01/08/2014 07:08 AM, Barry Warsaw wrote:
How hard would it be to put together some sample branches that provide concrete examples of the various options?
My own opinion could easily be influenced by having some hands-on time with actual code, and I suspect even Guido could be influenced if he could pull some things up in his editor and take a look around.
I've uploaded a prototype here:
https://bitbucket.org/larry/python-clinic-buffer
I have now received exactly zero feedback about the prototype, which suggests people aren't using it. In an attempt to jump-start this conversation, I've created a new repository containing the "concrete examples of the various options" that Barry proposed above. You may find it here:
https://bitbucket.org/larry/clinic-buffer-samples/src
In it I converted Modules/_pickle.c four different ways. There's a README, please read it.
People who want to change how Clinic writes its output: this is your big chance. Comment on these samples, or produce your own counterexamples, or something. If you can enough people on your side maybe Clinic will change. If there is no further debate on this topic, nothing will happen and Clinic will not change.
*/arry*
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rmsr%40lab.net
On Tue, Jan 14, 2014 at 5:32 PM, Ryan Smith-Roberts <rmsr@lab.net> wrote:
NaN _pickle.using-sidefile.c /* not enough experience with it */
I hate to weasel like that. Intellectually I think I favor the sidefile over all other approaches for its cleanliness. But I'd have to actively use it in a workflow a bit to know how practical it is.
On 01/14/2014 05:32 PM, Ryan Smith-Roberts wrote:
Pondering it this afternoon, I thought of a configuration that minimizes both code churn and readability impact: two buffers. One at the top containing forward declarations and defines (an inline header file if you like), and the rest of the autogenerated code at the bottom. It's not obvious that AC currently supports this configuration, or backtracking of any kind.
Clinic is strictly one pass currently. I could add this feature to the prototype if there was sufficient interest; for now, I'd accept a patch to the clinic-buffer-samples repo adding a sample of your proposal. Please start with "_pickle.original.c", and add simulated (but deliberately invalid!) Clinic instructions for an authentic flair. I suggest the name "forward" for the destination, and "_pickle.using-forward.buffer.c" for the filename. I take it "forward" would get the methoddef_define, the docstring_prototype, and the parser_prototype, "block" would get the impl_prototype, and "buffer" would get the docstring_definition and the parser_definition? I'm happy to collect votes for this approach too. I'll put you down as a +1 //arry/
On 01/14/2014 12:22 PM, Larry Hastings wrote:
On 01/11/2014 07:35 PM, Larry Hastings wrote:
I've uploaded a prototype here:
[...] I've created a new repository containing the "concrete examples of the various options" that Barry proposed above. You may find it here:
I've added a fourth feature to the prototype: set line_prefix lets you set a string that is prepended to every line of code generated by Clinic. Documentation is in the text file in the root. I also updated the clinic-buffer-samples repository to match. There's now a "prefixes" subdirectory, with copies of all the samples adding a per-line prefix of "/*clinic*/ ". Does that make Clinic any easier to swallow for anybody? Cheers, //arry/
On 01/14/2014 08:31 PM, Larry Hastings wrote:
I've added a fourth feature to the prototype:
set line_prefix
lets you set a string that is prepended to every line of code generated by Clinic.
Without the coloring support of my editor I would find that very useful indeed. But since I have coloring support (as soon as I hack it in, anyway ;), I'll vote +0.25. -- ~Ethan~
Larry Hastings <larry@hastings.org> wrote:
Thanks for doing this! +1 for the sidefile, -1 for the current approach, +-0 for the rest. Stefan Krah
On 07/01/2014 19:53, Antoine Pitrou wrote:
Hello,
Several core developers a bit unhappy with the way Argument Clinic currently scatters generated code into hand-written C modules. The opinion is that it makes C files more confusing and annoying to navigate through.
Several solutions have been proposed: - move all generated code to separate C files, which would then be #included'd into the main module file
- gather all generated code to a single place in the C module file, for example near the end (Larry's "accumulator" idea)
- prefix all Clinic-generated lines with a recognizable marker, e.g. "/* AC */"
What do you think?
Regards
Antoine.
Maybe overkill but why not follow 3 with 2 at the end of the file, the marker to be a very clear /* Generated by Argument Clinic - DO NOT EDIT BELOW THIS LINE */ or whatever wording is appropriate in this case. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On 01/07/2014 12:46 PM, Mark Lawrence wrote:
Maybe overkill but why not follow 3 with 2 at the end of the file, the marker to be a very clear /* Generated by Argument Clinic - DO NOT EDIT BELOW THIS LINE */ or whatever wording is appropriate in this case.
For what it's worth, if we use the "accumulator" approach I propose that the generated code doesn't go at the very end of the file. Instead, I suggest they should go *near* the end, below the implementations of the module / class methods, but above the methoddef/type structures and the module init function. My reasoning: when I navigate CPython C files implementing a module or a type, when I know what entry point I want I just search for its name. When I don't know what I want, I jump to the end, then scroll up until I find the name in the init function or the structures. So I wouldn't want the code at the very end; that would screw up that navigation mode. //arry/
On Tue, Jan 7, 2014 at 6:24 PM, Larry Hastings <larry@hastings.org> wrote:
On 01/07/2014 12:46 PM, Mark Lawrence wrote:
Maybe overkill but why not follow 3 with 2 at the end of the file, the marker to be a very clear /* Generated by Argument Clinic - DO NOT EDIT BELOW THIS LINE */ or whatever wording is appropriate in this case.
For what it's worth, if we use the "accumulator" approach I propose that the generated code doesn't go at the very end of the file. Instead, I suggest they should go *near* the end, below the implementations of the module / class methods, but above the methoddef/type structures and the module init function.
If it is accumulated in a single location should it just be a single block for everything towards the end? Then forward declarations would go away (you could still have it as a comment to copy-and-paste where you define the implementation) and you can have a single macro for the PyMethodDef values, each class, etc. If you accumulated the PyMethodDef values into a single macro it would help make up for the convenience lost of converting a function by just cutting the old call signature up to the new *_impl() function.
My reasoning: when I navigate CPython C files implementing a module or a type, when I know what entry point I want I just search for its name. When I don't know what I want, I jump to the end, then scroll up until I find the name in the init function or the structures. So I wouldn't want the code at the very end; that would screw up that navigation mode.
That's how I navigate as well.
On 01/07/2014 03:38 PM, Brett Cannon wrote:
On Tue, Jan 7, 2014 at 6:24 PM, Larry Hastings <larry@hastings.org <mailto:larry@hastings.org>> wrote:
For what it's worth, if we use the "accumulator" approach I propose that the generated code doesn't go at the very end of the file. Instead, I suggest they should go *near* the end, below the implementations of the module / class methods, but above the methoddef/type structures and the module init function.
If it is accumulated in a single location should it just be a single block for everything towards the end? Then forward declarations would go away (you could still have it as a comment to copy-and-paste where you define the implementation) and you can have a single macro for the PyMethodDef values, each class, etc. If you accumulated the PyMethodDef values into a single macro it would help make up for the convenience lost of converting a function by just cutting the old call signature up to the new *_impl() function.
I *think* that would complicate some use cases. People occasionally call these parsing functions from other functions, or spread their methoddef / typeobject structures throughout the file rather than putting them all at the end. I'm proposing that the blob of text immediately between the Clinic input and the body of the impl contain (newlines added here for clarity): static char *parsing_function_doc; static PyObject * parsing_function(...); #define PARSING_FUNCTION_METHODDEF \ { ... } static PyObject * parsing_function_impl(...) Then the "accumulator" would get the text of the docstring and the definition of the parsing_function. On the other hand, if we wanted to take this opportunity to force everyone to standardize (all methoddefs and typeobjects go at the end!) we could probably make it work with one giant block near the end. Or I could make it flexible on what went into the accumulator and what went into the normal output block, and the default could be everything-in-the-accumulator. Making the common easy and the uncommon possible and all that. Yeah, that seems best. //arry/
On Tue, Jan 7, 2014 at 7:07 PM, Larry Hastings <larry@hastings.org> wrote:
On 01/07/2014 03:38 PM, Brett Cannon wrote:
On Tue, Jan 7, 2014 at 6:24 PM, Larry Hastings <larry@hastings.org> wrote:
For what it's worth, if we use the "accumulator" approach I propose that the generated code doesn't go at the very end of the file. Instead, I suggest they should go *near* the end, below the implementations of the module / class methods, but above the methoddef/type structures and the module init function.
If it is accumulated in a single location should it just be a single block for everything towards the end? Then forward declarations would go away (you could still have it as a comment to copy-and-paste where you define the implementation) and you can have a single macro for the PyMethodDef values, each class, etc. If you accumulated the PyMethodDef values into a single macro it would help make up for the convenience lost of converting a function by just cutting the old call signature up to the new *_impl() function.
I *think* that would complicate some use cases. People occasionally call these parsing functions from other functions, or spread their methoddef / typeobject structures throughout the file rather than putting them all at the end.
I'm proposing that the blob of text immediately between the Clinic input and the body of the impl contain (newlines added here for clarity):
static char *parsing_function_doc;
static PyObject * parsing_function(...);
#define PARSING_FUNCTION_METHODDEF \ { ... }
static PyObject * parsing_function_impl(...)
Then the "accumulator" would get the text of the docstring and the definition of the parsing_function.
On the other hand, if we wanted to take this opportunity to force everyone to standardize (all methoddefs and typeobjects go at the end!) we could probably make it work with one giant block near the end.
Or I could make it flexible on what went into the accumulator and what went into the normal output block, and the default could be everything-in-the-accumulator. Making the common easy and the uncommon possible and all that. Yeah, that seems best.
So let's make this idea concrete to focus a possible discussion. Using the example from the Clinic HOWTO and converting to how I see it working: #################### /*[clinic input] pickle.Pickler.dump obj: 'O' The object to be pickled. / Write a pickled representation of obj to the open file. [clinic start generated code]*/ static PyObject * pickle_Pickler_dump_impl(PyObject *self, PyObject *obj) /*[clinic end generated code: checksum=3bd30745bf206a48f8b576a1da3d90f55a0a4187]*/ { /* Check whether the Pickler was initialized correctly (issue3664). Developers often forget to call __init__() in their subclasses, which would trigger a segfault without this check. */ if (self->write == NULL) { PyErr_Format(PicklingError, "Pickler.__init__() was not called by %s.__init__()", Py_TYPE(self)->tp_name); return NULL; } if (_Pickler_ClearBuffer(self) < 0) return NULL ... } ... /*[clinic accumulate]*/ PyDoc_STRVAR(pickle_Pickler_dump__doc__, "Write a pickled representation of obj to the open file.\n" "\n" static PyObject * _pickle_Pickler_dump(PyObject *args) { ... return pickle_Pickler_dump_impl(...); } #define _PICKLE_PICKLER_DUMP_METHODDEF \ {"dump", (PyCFunction)_pickle_Pickler_dump, METH_O, _pickle_Pickler_dump__doc__}, ... any other pickler.Pickler Clinic stuff that does not directly involve the the impl function ... #define _PICKLE_PICKLER_METHODDEF_ACCUMULATED \ _PICKLE_PICKLER_DUMP_METHODDEF \ ... any other MethodDef entries for pickle.Pickler /*[clinic end accumulate: checksum=0123456789]*/ ... pickle.Pickler struct where _PICKLE_PICKLER_METHODDEF_ACCUMULATED is all that is needed for the non-magical class methods ... ########################### Another potential perk of doing a gathering of Clinic output is that if we take it to it's logical conclusion, then you can start to do things like define a method like pickle.Pickler.__init__, etc., have Clinic handle docstrings for modules and classes, and then it can end up spitting out the type struct entirely for you, negating the typical need to do all of that by hand (I don't know about the rest of you but I always just copy and paste that struct anyway, so having a tool slot in the right method names for the right positions would save me busy work). It could then go as far as then spit out the module initialization function definition line and then all you would need to do is fill that in; Clinic could handle all other module-level details for you in the very common case.
On 01/08/2014 07:33 AM, Brett Cannon wrote:
So let's make this idea concrete to focus a possible discussion. Using the example from the Clinic HOWTO and converting to how I see it working: [...]
Yep. And what I was proposing is much the same, except there are a couple extra lines in the "generated code" section. I'd keep the #define for the methoddef there, and add a prototype for the generated parsing function (_pickle_Pickler_dump) and the docstring. #################### /*[clinic input] pickle.Pickler.dump obj: 'O' The object to be pickled. / Write a pickled representation of obj to the open file. [clinic start generated code]*/ PyDoc_VAR(pickle_Pickler_dump__doc__); static PyObject * _pickle_Pickler_dump(PyObject *args); #define _PICKLE_PICKLER_DUMP_METHODDEF \ {"dump", (PyCFunction)_pickle_Pickler_dump, METH_O, _pickle_Pickler_dump__doc__}, static PyObject * pickle_Pickler_dump_impl(PyObject *self, PyObject *obj) /*[clinic end generated code: checksum=3bd30745bf206a48f8b576a1da3d90f55a0a4187]*/ { /* Check whether the Pickler was initialized correctly (issue3664). Developers often forget to call __init__() in their subclasses, which would trigger a segfault without this check. */ ... }
Another potential perk of doing a gathering of Clinic output is that if we take it to it's logical conclusion, then you can start to do things like define a method like pickle.Pickler.__init__, etc., have Clinic handle docstrings for modules and classes, and then it can end up spitting out the type struct entirely for you, negating the typical need to do all of that by hand (I don't know about the rest of you but I always just copy and paste that struct anyway, so having a tool slot in the right method names for the right positions would save me busy work).
Surely new code should use the functional API for creating types? Anyway, yes, in the future it would be nice to get rid of a bunch of the busywork associated with implementing a Python builtin type, and Argument Clinic could definitely help with that. //arry/
On Wed, Jan 8, 2014 at 10:46 AM, Larry Hastings <larry@hastings.org> wrote:
On 01/08/2014 07:33 AM, Brett Cannon wrote:
So let's make this idea concrete to focus a possible discussion. Using the example from the Clinic HOWTO and converting to how I see it working: [...]
Yep. And what I was proposing is much the same, except there are a couple extra lines in the "generated code" section. I'd keep the #define for the methoddef there, and add a prototype for the generated parsing function (_pickle_Pickler_dump) and the docstring.
I assume that's for flexibility in case someone has their module structured in a way that doesn't lend itself to having it all accumulated at the end of the file? Or is there something I'm overlooking? I would assume being able to put the accumulator block where ever you want with enough forward declarations would still be enough to allow for it to work with almost any structured format of a file and have almost all the generated code in a single place. I can definitely live with what you are proposing, just trying to understand the logic as shifting almost all generated stuff in a single place does make Clinic comments read like fancy docstrings which is nice.
####################
/*[clinic input] pickle.Pickler.dump
obj: 'O' The object to be pickled. /
Write a pickled representation of obj to the open file. [clinic start generated code]*/ PyDoc_VAR(pickle_Pickler_dump__doc__);
static PyObject * _pickle_Pickler_dump(PyObject *args);
#define _PICKLE_PICKLER_DUMP_METHODDEF \ {"dump", (PyCFunction)_pickle_Pickler_dump, METH_O, _pickle_Pickler_dump__doc__},
static PyObject * pickle_Pickler_dump_impl(PyObject *self, PyObject *obj) /*[clinic end generated code: checksum=3bd30745bf206a48f8b576a1da3d90f55a0a4187]*/ { /* Check whether the Pickler was initialized correctly (issue3664). Developers often forget to call __init__() in their subclasses, which would trigger a segfault without this check. */ ... }
Another potential perk of doing a gathering of Clinic output is that if we take it to it's logical conclusion, then you can start to do things like define a method like pickle.Pickler.__init__, etc., have Clinic handle docstrings for modules and classes, and then it can end up spitting out the type struct entirely for you, negating the typical need to do all of that by hand (I don't know about the rest of you but I always just copy and paste that struct anyway, so having a tool slot in the right method names for the right positions would save me busy work).
Surely new code should use the functional API for creating types?
Yes. Shows how long it has been since I have written a C type from scratch. =)
Anyway, yes, in the future it would be nice to get rid of a bunch of the busywork associated with implementing a Python builtin type, and Argument Clinic could definitely help with that.
I think that will be the big long-term win; taking out nearly all boilerplate in creating an extension module and maintaining it (in case something changes, e.g. the module init function signature).
On 01/08/2014 08:04 AM, Brett Cannon wrote:
On Wed, Jan 8, 2014 at 10:46 AM, Larry Hastings <larry@hastings.org <mailto:larry@hastings.org>> wrote:
Yep. And what I was proposing is much the same, except there are a couple extra lines in the "generated code" section. I'd keep the #define for the methoddef there, and add a prototype for the generated parsing function (_pickle_Pickler_dump) and the docstring.
I assume that's for flexibility in case someone has their module structured in a way that doesn't lend itself to having it all accumulated at the end of the file? Or is there something I'm overlooking?
No, you're not overlooking anything, that's why. It's for files that have getsetdef / methoddef / typeobject structures all over the place instead of keeping them all at the end. My mindset is trying to avoid requiring big changes for Argument Clinic support like "step 87: now move all your getsetdef / methoddef / typeobject to the end of your file, below the accumulator output block". Argument Clinic is contributing enough churn as it is don'tchathink! //arry/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/07/2014 02:53 PM, Antoine Pitrou wrote:
- prefix all Clinic-generated lines with a recognizable marker, e.g. "/* AC */"
+1. I would wrap generated code in even-more-visually-distinct markers, both before and after, e.g.:: /* ------------------------- Begin ArgumentClinic ---------------- */ /* ------------------------- End ArgumentClinic ------------------ */ I think delineating gencode blocks this way makes it easier to ignore them (or find them, if needed). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLMcssACgkQ+gerLs4ltQ5dSACfSEpN2E1EU/AAJhOiaQr1TKgg jZAAn2Wok6cr1suhwOfEgFZmqlsJ6HB8 =AT9/ -----END PGP SIGNATURE-----
Antoine Pitrou <solipsis@pitrou.net> wrote:
Several solutions have been proposed: - move all generated code to separate C files, which would then be #included'd into the main module file
+1 for the reasons that Serhiy has listed. Additionally, if custom parsers are implemented, the generated code will take up even more space (look e.g. at Cython's custom parsers). Stefan Krah
On Tue, Jan 7, 2014 at 4:44 PM, Stefan Krah <stefan@bytereef.org> wrote:
Antoine Pitrou <solipsis@pitrou.net> wrote:
Several solutions have been proposed: - move all generated code to separate C files, which would then be #included'd into the main module file
+1 for the reasons that Serhiy has listed. Additionally, if custom parsers are implemented, the generated code will take up even more space (look e.g. at Cython's custom parsers).
Guido has already said he hates constructing files that way so that simply isn't going to happen. I personally don't care about this whole discussion (and I suspect people being quiet don't either). At this point the amount of arguing on this topic could have been used more constructively converting code and then, if necessary, tweaking the output of Argument Clinic later.
Brett Cannon <brett@python.org> wrote:
I personally don't care about this whole discussion (and I suspect people being quiet don't either). At this point the amount of arguing on this topic could have been used more constructively converting code and then, if necessary, tweaking the output of Argument Clinic later.
Serhiy, who started the discussion in another thread, is converting modules at a rapid pace. Stefan Krah
On 8 Jan 2014 06:24, "Brett Cannon" <brett@python.org> wrote:
On Tue, Jan 7, 2014 at 4:44 PM, Stefan Krah <stefan@bytereef.org> wrote:
Antoine Pitrou <solipsis@pitrou.net> wrote:
Several solutions have been proposed: - move all generated code to separate C files, which would then be #included'd into the main module file
+1 for the reasons that Serhiy has listed. Additionally, if custom
parsers
are implemented, the generated code will take up even more space (look e.g. at Cython's custom parsers).
Guido has already said he hates constructing files that way so that simply isn't going to happen.
I personally don't care about this whole discussion (and I suspect people being quiet don't either). At this point the amount of arguing on this topic could have been used more constructively converting code and then, if necessary, tweaking the output of Argument Clinic later.
I haven't had a chance to look at any of the newly converted code (due to vacation and linux.conf.au), so I'm happy to take the word of the folks doing the conversion that the current behaviour is inconvenient. I think the split VCS history where changing clinic's output without changing the function declarations *doesn't* show up as altering the manually maintained source files (but only clinic and separate generated "XYZ_clinic.c" files) is a compelling practical argument in favour of the split file approach, even if it makes execution jump around a little strangely. Failing that, I like Larry's proposal to switch to generating only prototypes inline and having the wrapper implementations at a common point in each file, reducing the visible boilerplate when looking at individual functions. Cheers, Nick.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
participants (18)
-
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
Ethan Furman -
Georg Brandl -
Larry Hastings -
Mark Lawrence -
Meador Inge -
Nick Coghlan -
Raymond Hettinger -
Ryan Smith-Roberts -
Serhiy Storchaka -
Stefan Krah -
Stefan Krah -
Tres Seaver -
Yury Selivanov -
Zachary Ware