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.
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
Larry Hastings la...@hastings.org 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
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.
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
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,
On Tue, Jan 14, 2014 at 2:22 PM, Larry Hastings la...@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
On 01/14/2014 12:48 PM, Zachary Ware wrote:
On Tue, Jan 14, 2014 at 2:22 PM, Larry Hastings la...@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
On Tue, Jan 14, 2014 at 3:22 PM, Larry Hastings la...@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
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
On Tue, 14 Jan 2014 12:22:12 -0800
Larry Hastings la...@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
On Jan 14, 2014, at 9:12 PM, Antoine Pitrou 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 full -1 on commingling
generated code with hand edited code.
On Tue, Jan 14, 2014 at 2:54 PM, Larry Hastings la...@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
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
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
On 01/14/2014 01:38 PM, Raymond Hettinger wrote:
On Jan 14, 2014, at 9:12 PM, Antoine Pitrou solip...@pitrou.net
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
14.01.14 23:38, Raymond Hettinger написав(ла):
On Jan 14, 2014, at 9:12 PM, Antoine Pitrou solip...@pitrou.net
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
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.
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
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
On Tue, Jan 14, 2014 at 5:32 PM, Ryan Smith-Roberts r...@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
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.
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
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
On Tue, Jan 14, 2014 at 3:12 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 14 Jan 2014 12:22:12 -0800
Larry Hastings la...@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,
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
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
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
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
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
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
On Tue, Jan 7, 2014 at 7:07 PM, Larry Hastings la...@hastings.org wrote:
On 01/07/2014 03:38 PM, Brett Cannon wrote:
On Tue, Jan 7, 2014 at 6:24 PM, Larry Hastings la...@hastings.org wrote:
For what it's worth, if we use the accumulator approach I propose
that the generated code doesn't
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
On Wed, Jan 8, 2014 at 10:46 AM, Larry Hastings la...@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
On 01/08/2014 08:04 AM, Brett Cannon wrote:
On Wed, Jan 8, 2014 at 10:46 AM, Larry Hastings la...@hastings.org
mailto:la...@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
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
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
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
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
On Tue, 07 Jan 2014 12:03:00 -0800
Ethan Furman et...@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
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
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
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
On 01/07/2014 12:07 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:03:00 -0800
Ethan Furman et...@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
On Tue, 07 Jan 2014 12:33:11 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/07/2014 12:07 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:03:00 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
- move all generated code to separate C files,
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]
-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.::
/*
On 01/07/2014 01:04 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:33:11 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/07/2014 12:07 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:03:00 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
-
Antoine Pitrou solip...@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
On Tue, Jan 7, 2014 at 4:44 PM, Stefan Krah ste...@bytereef.org wrote:
Antoine Pitrou solip...@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
Brett Cannon br...@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
On 8 Jan 2014 06:24, Brett Cannon br...@python.org wrote:
On Tue, Jan 7, 2014 at 4:44 PM, Stefan Krah ste...@bytereef.org wrote:
Antoine Pitrou solip...@pitrou.net wrote:
Several solutions have been proposed:
- move all generated code to separate C files, which would then be
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
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
On Tue, Jan 7, 2014 at 6:24 PM, Larry Hastings la...@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
On 01/07/2014 03:38 PM, Brett Cannon wrote:
On Tue, Jan 7, 2014 at 6:24 PM, Larry Hastings la...@hastings.org
mailto:la...@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.
56 matches
Mail list logo
