Re: [Python-Dev] Changing Clinic's output

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 tex

Re: [Python-Dev] Changing Clinic's output

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.

Re: [Python-Dev] Changing Clinic's output

Larry Hastings wrote: > https://bitbucket.org/larry/clinic-buffer-samples/src Thanks for doing this! +1 for the sidefile, -1 for the current approach, +-0 for the rest. Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org https://mail

Re: [Python-Dev] Changing Clinic's output

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 ta

Re: [Python-Dev] Changing Clinic's output

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.

Re: [Python-Dev] Changing Clinic's output

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 ha

Re: [Python-Dev] Changing Clinic's output

On Tue, Jan 14, 2014 at 3:12 PM, Antoine Pitrou wrote: On Tue, 14 Jan 2014 12:22:12 -0800 > Larry Hastings 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 o

Re: [Python-Dev] Changing Clinic's output

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: https://bitbucket.org/larry/python-clinic-buffer [...] I've created a new repository containing the "concrete examples of the various options" that Barry proposed

Re: [Python-Dev] Changing Clinic's output

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 au

Re: [Python-Dev] Changing Clinic's output

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.

Re: [Python-Dev] Changing Clinic's output

On Tue, Jan 14, 2014 at 5:32 PM, Ryan Smith-Roberts 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 b

Re: [Python-Dev] Changing Clinic's output

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 c

Re: [Python-Dev] Changing Clinic's output

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 wh

Re: [Python-Dev] Changing Clinic's output

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

Re: [Python-Dev] Changing Clinic's output

14.01.14 23:38, Raymond Hettinger написав(ла): On Jan 14, 2014, at 9:12 PM, Antoine Pitrou mailto:solip...@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 ful

Re: [Python-Dev] Changing Clinic's output

On 01/14/2014 01:38 PM, Raymond Hettinger wrote: On Jan 14, 2014, at 9:12 PM, Antoine Pitrou > 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

Re: [Python-Dev] Changing Clinic's output

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

Re: [Python-Dev] Changing Clinic's output

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 eas

Re: [Python-Dev] Changing Clinic's output

On Tue, Jan 14, 2014 at 2:54 PM, Larry Hastings 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-buffe

Re: [Python-Dev] Changing Clinic's output

On Jan 14, 2014, at 9:12 PM, Antoine Pitrou 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 every

Re: [Python-Dev] Changing Clinic's output

On Tue, 14 Jan 2014 12:22:12 -0800 Larry Hastings 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

Re: [Python-Dev] Changing Clinic's output

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

Re: [Python-Dev] Changing Clinic's output

On Tue, Jan 14, 2014 at 3:22 PM, Larry Hastings 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 coul

Re: [Python-Dev] Changing Clinic's output

On 01/14/2014 12:48 PM, Zachary Ware wrote: On Tue, Jan 14, 2014 at 2:22 PM, Larry Hastings 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 som

Re: [Python-Dev] Changing Clinic's output

On Tue, Jan 14, 2014 at 2:22 PM, Larry Hastings 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.p

Re: [Python-Dev] Changing Clinic's output

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, a

Re: [Python-Dev] Changing Clinic's output

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 h

Re: [Python-Dev] Changing Clinic's output

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 o

Re: [Python-Dev] Changing Clinic's output

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 histor

Re: [Python-Dev] Changing Clinic's output

On 01/08/2014 08:04 AM, Brett Cannon wrote: On Wed, Jan 8, 2014 at 10:46 AM, Larry Hastings > 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 metho

Re: [Python-Dev] Changing Clinic's output

On Wed, Jan 8, 2014 at 10:46 AM, Larry Hastings 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 propos

Re: [Python-Dev] Changing Clinic's output

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 "g

Re: [Python-Dev] Changing Clinic's output

On Tue, Jan 7, 2014 at 7:07 PM, Larry Hastings wrote: > > > On 01/07/2014 03:38 PM, Brett Cannon wrote: > > On Tue, Jan 7, 2014 at 6:24 PM, Larry Hastings 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

Re: [Python-Dev] Changing Clinic's output

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 influenc

Re: [Python-Dev] Changing Clinic's output

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 co

Re: [Python-Dev] Changing Clinic's output

On 01/07/2014 03:38 PM, Brett Cannon wrote: On Tue, Jan 7, 2014 at 6:24 PM, Larry Hastings > 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 the

Re: [Python-Dev] Changing Clinic's output

On Tue, Jan 7, 2014 at 6:24 PM, Larry Hastings 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

Re: [Python-Dev] Changing Clinic's output

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 his

Re: [Python-Dev] Changing Clinic's output

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

Re: [Python-Dev] Changing Clinic's output

On 8 Jan 2014 06:24, "Brett Cannon" wrote: > > > > > On Tue, Jan 7, 2014 at 4:44 PM, Stefan Krah wrote: >> >> Antoine Pitrou 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 >> >

Re: [Python-Dev] Changing Clinic's output

Brett Cannon 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 Cli

Re: [Python-Dev] Changing Clinic's output

On Tue, Jan 7, 2014 at 4:44 PM, Stefan Krah wrote: > Antoine Pitrou 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

Re: [Python-Dev] Changing Clinic's output

Antoine Pitrou 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

Re: [Python-Dev] Changing Clinic's output

On 01/07/2014 01:04 PM, Antoine Pitrou wrote: On Tue, 07 Jan 2014 12:33:11 -0800 Ethan Furman wrote: On 01/07/2014 12:07 PM, Antoine Pitrou wrote: On Tue, 07 Jan 2014 12:03:00 -0800 Ethan Furman wrote: On 01/07/2014 11:53 AM, Antoine Pitrou wrote: - move all generated code to separate C fi

Re: [Python-Dev] Changing Clinic's output

-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.:: /* -

Re: [Python-Dev] Changing Clinic's output

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]

Re: [Python-Dev] Changing Clinic's output

On Tue, 07 Jan 2014 12:33:11 -0800 Ethan Furman wrote: > On 01/07/2014 12:07 PM, Antoine Pitrou wrote: > > On Tue, 07 Jan 2014 12:03:00 -0800 > > Ethan Furman wrote: > >> On 01/07/2014 11:53 AM, Antoine Pitrou wrote: > >>> > >>> - move all generated code to separate C files, which would then be >

Re: [Python-Dev] Changing Clinic's output

On 01/07/2014 12:07 PM, Antoine Pitrou wrote: On Tue, 07 Jan 2014 12:03:00 -0800 Ethan Furman 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 disl

Re: [Python-Dev] Changing Clinic's output

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

Re: [Python-Dev] Changing Clinic's output

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

Re: [Python-Dev] Changing Clinic's output

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

Re: [Python-Dev] Changing Clinic's output

On Tue, 07 Jan 2014 12:03:00 -0800 Ethan Furman 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 ow

Re: [Python-Dev] Changing Clinic's output

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 bee

Re: [Python-Dev] Changing Clinic's output

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 exampl

Re: [Python-Dev] Changing Clinic's output

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. > >