After the latest Argument Clinic updates my patches began to look much better. Thank you Larry. Now Argument Clinic supports output to side file (this is not default, you should specify "output preset file" at the start of first clinic declaration). I already wrote about this here, but it seems my post got lost in the heart of one of the numerous threads and was not noticed. So I repeat it as a separate thread. Now generated files have suffixes .clinic.c. I think it will be better, if they will end at special suffix (.c.clinic or even just .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. 4. .c suffix at the end lies. This is not compilable C source file. This file should be included in other C source file. This will confuse accidental user and other tools. Including Argument Clinic itself, this is why it inserts the "preserve" directive at the start of generated file. But other tools have no such sign. My attempt to convince Larry on IRC failed. He agreed to change his opinion only if other core developers persuade him. I ask you to help me convince Larry.
On Sat, Jan 18, 2014 at 8:02 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
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.
A point for the contrary side: In any editor or IDE with syntax highlighting, a .clinic.c file will be highlighted as C code, but it would take extra configuration to handle a .clinic file that way. But that's a relatively minor consideration (AIUI most people won't be looking at the .clinic files much, and for those who do, configure the editor appropriately). ChrisA
On 18 Jan 2014 19:08, "Chris Angelico" <rosuav@gmail.com> wrote:
On Sat, Jan 18, 2014 at 8:02 PM, Serhiy Storchaka <storchaka@gmail.com>
wrote:
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.
A point for the contrary side: In any editor or IDE with syntax highlighting, a .clinic.c file will be highlighted as C code, but it would take extra configuration to handle a .clinic file that way. But that's a relatively minor consideration (AIUI most people won't be looking at the .clinic files much, and for those who do, configure the editor appropriately).
I can argue either side, but the biggest potential problem I see with Serhiy's suggestion is the likelihood of breaking automatic cross referencing of symbols in most IDEs, as well as causing possible issues for interactive debuggers. These are at least valid fragments of C files, even if they're not designed to be compiled independently. However, if both Visual Studio and gdb can still find the symbols correctly, even with the ".clinic" extension, then I would consider that a point strongly in favour of Serhiy's suggestion. Picking up on a side comment in Serhiy's post, based on my experience reviewing a patch that included changes to clinic input blocks, I'd also prefer if a parallel file was the default, and single file was opt in (or not allowed at all). Getting changes reviewed and merged is one of the biggest bottlenecks in our workflow, and the inline version of clinic is much harder to review due to the intermingled diff of clinic input and generated output. Cheers, Nick.
ChrisA _______________________________________________ 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
On 01/18/2014 05:28 AM, Nick Coghlan wrote:
However, if both Visual Studio and gdb can still find the symbols correctly, even with the ".clinic" extension, then I would consider that a point strongly in favour of Serhiy's suggestion.
No, that would be a lack of a point against Serhiy's suggestion. //arry/
18.01.14 15:28, Nick Coghlan написав(ла):
I can argue either side, but the biggest potential problem I see with Serhiy's suggestion is the likelihood of breaking automatic cross referencing of symbols in most IDEs, as well as causing possible issues for interactive debuggers. These are at least valid fragments of C files, even if they're not designed to be compiled independently. However, if both Visual Studio and gdb can still find the symbols correctly, even with the ".clinic" extension, then I would consider that a point strongly in favour of Serhiy's suggestion.
Good point. This idea did not come into my mind, and now I am almost ready to give up my proposals. But C allows you to include files with any extensions (.h, hpp, .h++, .c, .cpp, .inc, .gen, etc), and a powerful tool should monitor "#include"s not paying attention to expansions. On the other hand, simpler tools can work with filename masks, and for them it is much easier to add a new extension than to set exclude condition (the last option may not be supported at all). At least it is so with the tools that I use.
18.01.14 11:06, Chris Angelico написав(ла):
A point for the contrary side: In any editor or IDE with syntax highlighting, a .clinic.c file will be highlighted as C code, but it would take extra configuration to handle a .clinic file that way. But that's a relatively minor consideration (AIUI most people won't be looking at the .clinic files much, and for those who do, configure the editor appropriately).
Yes, this was the main Larry's objection. And as you, I think this is a minor consideration (for same reasons).
Serhiy Storchaka <storchaka@gmail.com> wrote:
Now generated files have suffixes .clinic.c. I think it will be better, if they will end at special suffix (.c.clinic or even just .clinic).
Can the output not go into a header file with static inline functions? I'd rather see memoryview.h than memoryview.clinic.c. Stefan Krah
On 1/18/2014 11:24 AM, Stefan Krah wrote:
Serhiy Storchaka <storchaka@gmail.com> wrote:
Now generated files have suffixes .clinic.c. I think it will be better, if they will end at special suffix (.c.clinic or even just .clinic).
Can the output not go into a header file with static inline functions?
I'd rather see memoryview.h than memoryview.clinic.c.
Same here. There's some history for this, but not for generated code. In Objects/stringlib, all of the files are .h files. They're really C code designed to be included by other .c files. Eric.
18.01.14 18:30, Eric V. Smith написав(ла):
Same here. There's some history for this, but not for generated code. In Objects/stringlib, all of the files are .h files. They're really C code designed to be included by other .c files.
Objects/stringlib files are hand-written. We should distinguish generated code from hand-written.
On 01/19/2014 06:35 AM, Serhiy Storchaka wrote:
18.01.14 18:30, Eric V. Smith написав(ла):
Same here. There's some history for this, but not for generated code. In Objects/stringlib, all of the files are .h files. They're really C code designed to be included by other .c files.
Objects/stringlib files are hand-written. We should distinguish generated code from hand-written.
We do. Generated files have .clinic. in the name. That is sufficient. -- ~Ethan~
On Sat, 18 Jan 2014 18:06:06 +0100 Stefan Krah <stefan@bytereef.org> wrote:
I'd rather see memoryview.h than memoryview.clinic.c.
Or, if this collides with Include/*, one of the following:
memoryview_func.h // public functions
memoryview_if.h // public interface
Objects/memoryview.clinic.h should be fine. Regards Antoine.
On Sat, 18 Jan 2014 18:18:49 +0100 Stefan Krah <stefan@bytereef.org> wrote:
Antoine Pitrou <solipsis@pitrou.net> wrote:
Objects/memoryview.clinic.h should be fine.
Last attempt:
Objects/memoryview.api.h
That is more neutral and describes what the file contains.
Disagreed. It's not an API in the sense that it's something that's designed to be called directly by third-party code. Regards Antoine.
Antoine Pitrou <solipsis@pitrou.net> wrote:
Objects/memoryview.api.h
That is more neutral and describes what the file contains.
Disagreed. It's not an API in the sense that it's something that's designed to be called directly by third-party code.
Right. Objects/memoryview.ac.h perhaps? I sort of dislike reading full words in filename extensions. Stefan Krah
Serhiy Storchaka <storchaka@gmail.com> wrote:
.ac is well known suffix of autoconf related files.
I know, but unless someone writes Objects/configure.c I think this won't be a problem.
And tail .h has same disadvantages as .c.
I'm not strongly inconvenienced by those you listed. Stefan Krah
18.01.14 19:09, Antoine Pitrou написав(ла):
On Sat, 18 Jan 2014 18:06:06 +0100 Stefan Krah <stefan@bytereef.org> wrote:
I'd rather see memoryview.h than memoryview.clinic.c.
Or, if this collides with Include/*, one of the following:
memoryview_func.h // public functions
memoryview_if.h // public interface
Objects/memoryview.clinic.h should be fine.
All my objections against .clinic.c are applicable to .clinic.h as well.
On Sat, Jan 18, 2014 at 12:10 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
18.01.14 19:09, Antoine Pitrou написав(ла):
On Sat, 18 Jan 2014 18:06:06 +0100 Stefan Krah <stefan@bytereef.org> wrote:
I'd rather see memoryview.h than memoryview.clinic.c.
Or, if this collides with Include/*, one of the following:
memoryview_func.h // public functions
memoryview_if.h // public interface
Objects/memoryview.clinic.h should be fine.
All my objections against .clinic.c are applicable to .clinic.h as well.
Would it be of any help for the clinic files to live in their own separate directory? Say, instead of Objects/memoryview.clinic.c, Clinic/memoryview.clinic.c? -- Zach
On 18/01/2014 05:09 pm, Antoine Pitrou wrote:
Or, if this collides with Include/*, one of the following:
memoryview_func.h // public functions
memoryview_if.h // public interface Objects/memoryview.clinic.h should be fine. Or maybe have a __clinic__ directory similar to __pycache__.
-- Richard
On 01/18/2014 01:02 AM, Serhiy Storchaka wrote:
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).
Apparently you do this at the command-line. In that case, you can make an 'alias' to hide the cumbersome expression. Perhaps you've already made one that ignores the ".hg" directory tree? If the generated file didn't end in a standard extension, editors won't automatically recognize them and won't code-color them. You tell me "everyone can easily reconfigure their editors" but it seems you writing an alias is unreasonable.
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.
My experience is that IDEs either show all files in the "project" (which should include the generated files anyway) or they show all files in the directory. So this concern assumes behavior that isn't true.
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.
How often do people edit *.c in a directory? And then, how often do people edit *.c in a directory and wouldn't want to see the Argument Clinic generated code?
4. .c suffix at the end lies. This is not compilable C source file. This file should be included in other C source file. This will confuse accidental user and other tools. Including Argument Clinic itself, this is why it inserts the "preserve" directive at the start of generated file. But other tools have no such sign.
This is nonsense. The contents of the file is 100% C. If you added the proper include files (by hand, not recommended) it would compile standalone. A lot of your suggestions assume no one would ever want to examine the generated code. But people will still want to look in there: * to set breakpoints * to make sure existing Argument Clinic generated code does what you wanted * when experimenting with Argument Clinic inputs So I don't see the need to make the generated files totally invisible. Later in the thread someone suggests that ".h" would be a better ending; I'm willing to consider that. (As in ".clinic.h".) After all, you do include it, and there's some precedent for C code in H files (the already-cited stringlib). Also, now I'm starting to worry that adding ".clinic.c" files to an IDE would mean the IDE would try to compile them. Can somebody who uses an IDE to compile Python code experiment with ".clinic.c" files and report back--is it possible to add them to your "project" in such a way that the compiler will notice when they changed but won't try to compile them standalone? I'm thinking specifically of MSVS, as that's explicitly supported by CPython, but I'm interested in results from other IDEs if people use them with CPython trunk. Serhiy: I appreciate your contributions, both to Python in general and to Argument Clinic specifically. And you're only doing this because you care. Still, I feel like you've never been shown a bikeshed you didn't have an opinion on. //arry/
Visual Studio will try to compile them if they end with .c, though this can be disabled on a per-file basis in the project file. Files ending in .h won't be compiled, though changes should be detected and cause the .c files that include them to be recompiled. .inl is also sometimes used as an extension for this purpose. I don't recall whether VS will add file associations for this type. Cheers, Steve Top-posted from my Windows Phone ________________________________ From: Larry Hastings<mailto:larry@hastings.org> Sent: 1/18/2014 10:58 To: python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev] .clinic.c vs .c.clinic On 01/18/2014 01:02 AM, Serhiy Storchaka wrote: 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). Apparently you do this at the command-line. In that case, you can make an 'alias' to hide the cumbersome expression. Perhaps you've already made one that ignores the ".hg" directory tree? If the generated file didn't end in a standard extension, editors won't automatically recognize them and won't code-color them. You tell me "everyone can easily reconfigure their editors" but it seems you writing an alias is unreasonable. 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. My experience is that IDEs either show all files in the "project" (which should include the generated files anyway) or they show all files in the directory. So this concern assumes behavior that isn't true. 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. How often do people edit *.c in a directory? And then, how often do people edit *.c in a directory and wouldn't want to see the Argument Clinic generated code? 4. .c suffix at the end lies. This is not compilable C source file. This file should be included in other C source file. This will confuse accidental user and other tools. Including Argument Clinic itself, this is why it inserts the "preserve" directive at the start of generated file. But other tools have no such sign. This is nonsense. The contents of the file is 100% C. If you added the proper include files (by hand, not recommended) it would compile standalone. A lot of your suggestions assume no one would ever want to examine the generated code. But people will still want to look in there: * to set breakpoints * to make sure existing Argument Clinic generated code does what you wanted * when experimenting with Argument Clinic inputs So I don't see the need to make the generated files totally invisible. Later in the thread someone suggests that ".h" would be a better ending; I'm willing to consider that. (As in ".clinic.h".) After all, you do include it, and there's some precedent for C code in H files (the already-cited stringlib). Also, now I'm starting to worry that adding ".clinic.c" files to an IDE would mean the IDE would try to compile them. Can somebody who uses an IDE to compile Python code experiment with ".clinic.c" files and report back--is it possible to add them to your "project" in such a way that the compiler will notice when they changed but won't try to compile them standalone? I'm thinking specifically of MSVS, as that's explicitly supported by CPython, but I'm interested in results from other IDEs if people use them with CPython trunk. Serhiy: I appreciate your contributions, both to Python in general and to Argument Clinic specifically. And you're only doing this because you care. Still, I feel like you've never been shown a bikeshed you didn't have an opinion on. /arry
On 19 January 2014 10:44, Steve Dower <Steve.Dower@microsoft.com> wrote:
Visual Studio will try to compile them if they end with .c, though this can be disabled on a per-file basis in the project file. Files ending in .h won't be compiled, though changes should be detected and cause the .c files that include them to be recompiled.
That sounds like a rather good argument for .clinic.h over .clinic.c :) My assessment of the thread is that .clinic.h will give us the best overall tool compatibility. I use Eli Bendersky's pss for my command line source searching needs, and should be able to update that to skip clinic files without much difficulty (rather than having to exclude them manually from every search). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 01/18/2014 10:36 PM, Nick Coghlan wrote:
On 19 January 2014 10:44, Steve Dower <Steve.Dower@microsoft.com> wrote:
Visual Studio will try to compile them if they end with .c, though this can be disabled on a per-file basis in the project file. Files ending in .h won't be compiled, though changes should be detected and cause the .c files that include them to be recompiled. That sounds like a rather good argument for .clinic.h over .clinic.c :)
My assessment of the thread is that .clinic.h will give us the best overall tool compatibility.
Yeah, I'm tipping pretty far towards "foo.c" -> "foo.clinic.h". But there's one onion in the ointment: what should "foo.h" generate? The day may yet arrive when we have Argument Clinic code in foo.{ch}. Not kidding, my best idea so far is "foo.clinic.h.h", //arry/
Am 19.01.2014 11:19, schrieb Larry Hastings:
On 01/18/2014 10:36 PM, Nick Coghlan wrote:
On 19 January 2014 10:44, Steve Dower <Steve.Dower@microsoft.com> wrote:
Visual Studio will try to compile them if they end with .c, though this can be disabled on a per-file basis in the project file. Files ending in .h won't be compiled, though changes should be detected and cause the .c files that include them to be recompiled. That sounds like a rather good argument for .clinic.h over .clinic.c :)
My assessment of the thread is that .clinic.h will give us the best overall tool compatibility.
Yeah, I'm tipping pretty far towards "foo.c" -> "foo.clinic.h".
But there's one onion in the ointment: what should "foo.h" generate? The day may yet arrive when we have Argument Clinic code in foo.{ch}.
Not kidding, my best idea so far is "foo.clinic.h.h",
Why not always put clinic into its own directory? Modules/mathmodule.c -> Modules/clinic/mathmodule.c.h Modules/mathmodule.h -> Modules/clinic/mathmodule.h.h At least that is consistent, allows easy exclusion in tools, and gets rid of the additional "clinic" in the filename. Georg
On 01/19/2014 03:32 AM, Georg Brandl wrote:
Am 19.01.2014 11:19, schrieb Larry Hastings:
On 01/18/2014 10:36 PM, Nick Coghlan wrote:
On 19 January 2014 10:44, Steve Dower <Steve.Dower@microsoft.com> wrote:
Visual Studio will try to compile them if they end with .c, though this can be disabled on a per-file basis in the project file. Files ending in .h won't be compiled, though changes should be detected and cause the .c files that include them to be recompiled. That sounds like a rather good argument for .clinic.h over .clinic.c :)
My assessment of the thread is that .clinic.h will give us the best overall tool compatibility.
Yeah, I'm tipping pretty far towards "foo.c" -> "foo.clinic.h".
But there's one onion in the ointment: what should "foo.h" generate? The day may yet arrive when we have Argument Clinic code in foo.{ch}.
Not kidding, my best idea so far is "foo.clinic.h.h",
Why not always put clinic into its own directory?
Modules/mathmodule.c -> Modules/clinic/mathmodule.c.h Modules/mathmodule.h -> Modules/clinic/mathmodule.h.h
At least that is consistent, allows easy exclusion in tools, and gets rid of the additional "clinic" in the filename.
+1 If AC will work with both .c and .h files. I think a separate directory is the way to go. -- ~Ethan~
On 01/19/2014 08:29 AM, Ethan Furman wrote:
On 01/19/2014 03:32 AM, Georg Brandl wrote:
Am 19.01.2014 11:19, schrieb Larry Hastings:
Not kidding, my best idea so far is "foo.clinic.h.h",
Why not always put clinic into its own directory?
Modules/mathmodule.c -> Modules/clinic/mathmodule.c.h Modules/mathmodule.h -> Modules/clinic/mathmodule.h.h
At least that is consistent, allows easy exclusion in tools, and gets rid of the additional "clinic" in the filename.
+1
If AC will work with both .c and .h files. I think a separate directory is the way to go.
In theory, Argument Clinic works with any file for which it can iterate over by lines and recognize comments. It current supports C and Python files and automatically recognizes a bunch of extensions. -------------------- Okay, I'm taking a poll. I will total your answers and take the result... strongly under advisement. ;-) The rules: * The poll will be over in 48 hours, maybe sooner if a winner emerges early. * Please express your vote from -1 to +1. -0 and +0 will only be differentiated during a tiebreaker. * If you don't vote for a contestant, your vote will be assumed to be 0. * You may change your vote at any time while the poll is still running. * If you wish to nominate a new contestant, you may. Please give the contestant a name, and express how it would transform the filenames "foo.c" and "foo.h". I would strongly prefer that all transformations be expressable using str.format(transformation, filename="foo.c", basename="foo", extension=".c") . The contestants so far: Contestant 1: "Add .clinic.h" foo.c -> foo.c.clinic.h foo.h -> foo.h.clinic.h Contestant 2: "Add .ac.h" foo.c -> foo.c.ac.h foo.h -> foo.h.ac.h Contestant 3: "Add .clinic" foo.c -> foo.c.clinic foo.h -> foo.h.clinic Contestant 4: "Put in clinic directory, add .h" foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h Contestant 5: "Put in __clinic__ directory, add .h" foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h I didn't add a contestant for what Stefan Krah originally suggested ("foo.c -> foo.h") because it's not clear how this would handle "foo.h". You'll notice the current behavior is no longer in the running, //arry/
Am 20.01.2014 09:05, schrieb Larry Hastings:
On 01/19/2014 08:29 AM, Ethan Furman wrote:
On 01/19/2014 03:32 AM, Georg Brandl wrote:
Am 19.01.2014 11:19, schrieb Larry Hastings:
Not kidding, my best idea so far is "foo.clinic.h.h",
Why not always put clinic into its own directory?
Modules/mathmodule.c -> Modules/clinic/mathmodule.c.h Modules/mathmodule.h -> Modules/clinic/mathmodule.h.h
At least that is consistent, allows easy exclusion in tools, and gets rid of the additional "clinic" in the filename.
+1
If AC will work with both .c and .h files. I think a separate directory is the way to go.
In theory, Argument Clinic works with any file for which it can iterate over by lines and recognize comments. It current supports C and Python files and automatically recognizes a bunch of extensions.
--------------------
Okay, I'm taking a poll. I will total your answers and take the result... strongly under advisement. ;-)
The rules: * The poll will be over in 48 hours, maybe sooner if a winner emerges early. * Please express your vote from -1 to +1. -0 and +0 will only be differentiated during a tiebreaker. * If you don't vote for a contestant, your vote will be assumed to be 0. * You may change your vote at any time while the poll is still running. * If you wish to nominate a new contestant, you may. Please give the contestant a name, and express how it would transform the filenames "foo.c" and "foo.h". I would strongly prefer that all transformations be expressable using str.format(transformation, filename="foo.c", basename="foo", extension=".c") .
The contestants so far:
Contestant 1: "Add .clinic.h"
foo.c -> foo.c.clinic.h foo.h -> foo.h.clinic.h
-0. (Clutters the directory.)
Contestant 2: "Add .ac.h"
foo.c -> foo.c.ac.h foo.h -> foo.h.ac.h
-1. (Autoconf...)
Contestant 3: "Add .clinic"
foo.c -> foo.c.clinic foo.h -> foo.h.clinic
-1. (Doesn't get included in global *.[ch] search, clutters the directory.)
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h
+1.
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h
-1. (Too complicated; this isn't Python packages we're talking about.) Georg
+1 for Contestant 4 for me as well, +0 for Contestant 5, -1 for the others. Same reasons as Georg, even where my votes are different.
On 1/20/2014 6:01 AM, Terry Reedy wrote:
On 1/20/2014 4:07 AM, Nick Coghlan wrote:
+1 for Contestant 4 for me as well, +0 for Contestant 5, -1 for the others. Same reasons as Georg, even where my votes are different.
Ditto for me.
Except that after reading other responses, I might switch 4 and 5, so make that +1 for either 4 or 5. -- Terry Jan Reedy
20.01.14 10:05, Larry Hastings написав(ла):
The contestants so far:
Contestant 1: "Add .clinic.h"
foo.c -> foo.c.clinic.h foo.h -> foo.h.clinic.h
-0.5.
Contestant 2: "Add .ac.h"
foo.c -> foo.c.ac.h foo.h -> foo.h.ac.h
-1.
Contestant 3: "Add .clinic"
foo.c -> foo.c.clinic foo.h -> foo.h.clinic
+1. (Doesn't get included in global *.[ch] search, generated files are located close to origins.)
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h
-1. (Generated files are located far from origins, directory name clutters the namespace of directory names).
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h
-0.5.
On 20 January 2014 21:14, Serhiy Storchaka <storchaka@gmail.com> wrote:
20.01.14 10:05, Larry Hastings написав(ла):
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h
-1. (Generated files are located far from origins, directory name clutters the namespace of directory names).
Larry's not talking about a top level directory here (at least I hope he isn't). This proposal would mean using "Objects/clinic", "Python/clinic", "Modules/clinic" as appropriate. That's substantially *less* directory clutter rather than more, just like __pycache__ vs the old model of implicitly creating adjacent .pyc and .pyo files. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
20.01.14 15:03, Nick Coghlan написав(ла):
On 20 January 2014 21:14, Serhiy Storchaka <storchaka@gmail.com> wrote:
20.01.14 10:05, Larry Hastings написав(ла):
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h
-1. (Generated files are located far from origins, directory name clutters the namespace of directory names).
Larry's not talking about a top level directory here (at least I hope he isn't). This proposal would mean using "Objects/clinic", "Python/clinic", "Modules/clinic" as appropriate.
This means the appearance of directories with the common name "clinic" in random places of the source tree. Some special name ("__clinic__", ".clinic") looks slightly less confusing to me.
Am 20.01.2014 14:31, schrieb Serhiy Storchaka:
20.01.14 15:03, Nick Coghlan написав(ла):
On 20 January 2014 21:14, Serhiy Storchaka <storchaka@gmail.com> wrote:
20.01.14 10:05, Larry Hastings написав(ла):
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h
-1. (Generated files are located far from origins, directory name clutters the namespace of directory names).
Larry's not talking about a top level directory here (at least I hope he isn't). This proposal would mean using "Objects/clinic", "Python/clinic", "Modules/clinic" as appropriate.
This means the appearance of directories with the common name "clinic" in random places of the source tree. Some special name ("__clinic__", ".clinic") looks slightly less confusing to me.
"clinic" shouldn't be such a common name in C soures :) Georg
20.01.14 20:09, Georg Brandl написав(ла):
Am 20.01.2014 14:31, schrieb Serhiy Storchaka:
20.01.14 15:03, Nick Coghlan написав(ла):
On 20 January 2014 21:14, Serhiy Storchaka <storchaka@gmail.com> wrote:
20.01.14 10:05, Larry Hastings написав(ла):
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h
-1. (Generated files are located far from origins, directory name clutters the namespace of directory names).
Larry's not talking about a top level directory here (at least I hope he isn't). This proposal would mean using "Objects/clinic", "Python/clinic", "Modules/clinic" as appropriate.
This means the appearance of directories with the common name "clinic" in random places of the source tree. Some special name ("__clinic__", ".clinic") looks slightly less confusing to me.
"clinic" shouldn't be such a common name in C soures :)
Sources tree already has one "clinic" directory (Tools/clinic/).
On 21 Jan 2014 08:20, "Serhiy Storchaka" <storchaka@gmail.com> wrote:
20.01.14 20:09, Georg Brandl написав(ла):
Am 20.01.2014 14:31, schrieb Serhiy Storchaka:
20.01.14 15:03, Nick Coghlan написав(ла):
On 20 January 2014 21:14, Serhiy Storchaka <storchaka@gmail.com> wrote:
20.01.14 10:05, Larry Hastings написав(ла):
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h
-1. (Generated files are located far from origins, directory name
clutters
the namespace of directory names).
Larry's not talking about a top level directory here (at least I hope he isn't). This proposal would mean using "Objects/clinic", "Python/clinic", "Modules/clinic" as appropriate.
This means the appearance of directories with the common name "clinic" in random places of the source tree. Some special name ("__clinic__", ".clinic") looks slightly less confusing to me.
"clinic" shouldn't be such a common name in C soures :)
Sources tree already has one "clinic" directory (Tools/clinic/).
This observation and the cjkcodecs comparison has prompted me to switch my votes for #4 and #5: +1 for __clinic__, +0 for clinic. I still prefer a subdirectory to adjacent files, though. 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
On 01/20/2014 05:03 AM, Nick Coghlan wrote:
On 20 January 2014 21:14, Serhiy Storchaka <storchaka@gmail.com> wrote:
20.01.14 10:05, Larry Hastings написав(ла):
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h
-1. (Generated files are located far from origins, directory name clutters the namespace of directory names). Larry's not talking about a top level directory here (at least I hope he isn't). This proposal would mean using "Objects/clinic", "Python/clinic", "Modules/clinic" as appropriate.
You're correct, I'm not talking about a top-level directory here. I'm talking about creating a "clinic" subdirectory in the same directory as the original file. The transformation suggested above was exact. //arry/
On 01/22/2014 08:20 AM, Serhiy Storchaka wrote:
20.01.14 13:14, Serhiy Storch
aka написав(ла):
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h
-0.5.
As far as 4 and 5 have equal total votes, I change my vote for 5 from -0.5 to -0.
Too late! The poll ended Tuesday evening at 11pm, PST (GMT -0800). ;-) And yes, with 13 votes cast, it ended with a tie between "clinic/{filename}.h" and "__clinic__/{filename}.h", both at +4. As officiant I get to be the tiebreaker. My thoughts so far: * A bunch of longtime Python core devs cast their votes for "__clinic__": Nick, Terry, Stefan, Brett, Barry. On the other hand, Antoine and Georg preferred "clinic". * We have the precendent of __pycache__, where we cache machine-generated code that's the equivalent of code that in a file that's a sibling of the __pycache__ directory. * But it's not a perfect metaphor. For one, this directory will be checked in; __pycache__ directories should not be checked in. For another, if you blow away a __pycache__ directory everything automatically works fine. If you blow away a directory of Clinic generated code, you have to rebuild it by hand. Until you do you've broken your build. * We also have the precedent of "stringlib", a directory containing a bunch of unpleasant-to-look-at headers containing C code. It's not machine-generated code. But it is templatized code, so it's kind of compile-time generated on the fly if you squint at it. And it is checked in. * We also have the precedent of some machine-generated C code that is checked in in the Python tree: Python-ast.c, Python-ast.h. (Maybe one or two more? I forget.) None of these files have funny double-underscores prepended to their names. Also: If you only examine the people who voted +1 on "clinic", the sum of their votes on "__clinic__" is -0.5. If you only examine the people who voted +1 on "__clinic__", the sum of their votes on "clinic" is +2. Therefore, the people who voted for "__clinic__" are pretty tolerant of "clinic". The people who voted for "clinic" are less tolerant of "__clinic__". And finally: The total positive votes for "clinic" were 6, and total for the minus -2. The total positive votes for "__clinic__" were 7, and the minus -3. So "__clinic__" seems slightly more divisive. I'm leaning towards "clinic", primarily because of precedents in CPython trunk. But also because it makes it look more on-purpose and permanent. And because it's more aesthetically pleasing to look at. //arry/
On 1/22/2014 4:41 PM, Larry Hastings wrote:
And yes, with 13 votes cast, it ended with a tie between "clinic/{filename}.h" and "__clinic__/{filename}.h", both at +4. As officiant I get to be the tiebreaker.
Yep.
My thoughts so far: * A bunch of longtime Python core devs cast their votes for "__clinic__": Nick, Terry, Stefan, Brett, Barry. On the other hand, Antoine and Georg preferred "clinic". * We have the precendent of __pycache__, where we cache machine-generated code that's the equivalent of code that in a file that's a sibling of the __pycache__ directory. * But it's not a perfect metaphor. For one, this directory will be checked in; __pycache__ directories should not be checked in. For another, if you blow away a __pycache__ directory everything automatically works fine. If you blow away a directory of Clinic generated code, you have to rebuild it by hand. Until you do you've broken your build. * We also have the precedent of "stringlib", a directory containing a bunch of unpleasant-to-look-at headers containing C code. It's not machine-generated code. But it is templatized code, so it's kind of compile-time generated on the fly if you squint at it. And it is checked in. * We also have the precedent of some machine-generated C code that is checked in in the Python tree: Python-ast.c, Python-ast.h. (Maybe one or two more? I forget.) None of these files have funny double-underscores prepended to their names.
Also: If you only examine the people who voted +1 on "clinic", the sum of their votes on "__clinic__" is -0.5. If you only examine the people who voted +1 on "__clinic__", the sum of their votes on "clinic" is +2. Therefore, the people who voted for "__clinic__" are pretty tolerant of "clinic". The people who voted for "clinic" are less tolerant of "__clinic__".
And finally: The total positive votes for "clinic" were 6, and total for the minus -2. The total positive votes for "__clinic__" were 7, and the minus -3. So "__clinic__" seems slightly more divisive.
I'm leaning towards "clinic", primarily because of precedents in CPython trunk. But also because it makes it look more on-purpose and permanent. And because it's more aesthetically pleasing to look at.
I think you nicely summarized the various thoughts on 'clinic/' versus '__clinic__'. -- Terry Jan Reedy
On Mon, 20 Jan 2014 00:05:16 -0800 Larry Hastings <larry@hastings.org> wrote:
On 01/19/2014 08:29 AM, Ethan Furman wrote:
On 01/19/2014 03:32 AM, Georg Brandl wrote:
Am 19.01.2014 11:19, schrieb Larry Hastings:
Not kidding, my best idea so far is "foo.clinic.h.h",
Why not always put clinic into its own directory?
Modules/mathmodule.c -> Modules/clinic/mathmodule.c.h Modules/mathmodule.h -> Modules/clinic/mathmodule.h.h
At least that is consistent, allows easy exclusion in tools, and gets rid of the additional "clinic" in the filename.
+1
If AC will work with both .c and .h files. I think a separate directory is the way to go.
In theory, Argument Clinic works with any file for which it can iterate over by lines and recognize comments. It current supports C and Python files and automatically recognizes a bunch of extensions.
--------------------
Okay, I'm taking a poll. I will total your answers and take the result... strongly under advisement. ;-)
The rules: * The poll will be over in 48 hours, maybe sooner if a winner emerges early. * Please express your vote from -1 to +1. -0 and +0 will only be differentiated during a tiebreaker. * If you don't vote for a contestant, your vote will be assumed to be 0. * You may change your vote at any time while the poll is still running. * If you wish to nominate a new contestant, you may. Please give the contestant a name, and express how it would transform the filenames "foo.c" and "foo.h". I would strongly prefer that all transformations be expressable using str.format(transformation, filename="foo.c", basename="foo", extension=".c") .
The contestants so far:
Contestant 1: "Add .clinic.h"
+1
Contestant 2: "Add .ac.h"
-0.5
Contestant 3: "Add .clinic"
-1
Contestant 4: "Put in clinic directory, add .h"
+1
Contestant 5: "Put in __clinic__ directory, add .h"
-0.5 Regards Antoine.
On Mon, Jan 20, 2014 at 2:05 AM, Larry Hastings <larry@hastings.org> wrote: Contestant 1: "Add .clinic.h"
foo.c -> foo.c.clinic.h foo.h -> foo.h.clinic.h
-0
Contestant 2: "Add .ac.h"
foo.c -> foo.c.ac.h foo.h -> foo.h.ac.h
-1
Contestant 3: "Add .clinic"
foo.c -> foo.c.clinic foo.h -> foo.h.clinic
-1 (This will break too many tools in the C/C++ tools ecosystem and I am not convinced by any of the arguments given those far.)
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h
+1
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h
-1 ("clinic" without the dunders more clear for a directory name.)
-- Meador
The contestants so far:
Contestant 1: "Add .clinic.h"
foo.c -> foo.c.clinic.h foo.h -> foo.h.clinic.h
+0
Contestant 2: "Add .ac.h"
foo.c -> foo.c.ac.h foo.h -> foo.h.ac.h
+1
Contestant 3: "Add .clinic"
foo.c -> foo.c.clinic foo.h -> foo.h.clinic
+0
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h
-1
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h
-1
On Mon, Jan 20, 2014 at 04:07:51PM +0100, Stefan Krah <stefan@bytereef.org> wrote:
Bonus points for any other directory name that is more self-descriptive. ;)
Argument Clinic is a PyArg_Parse* preprocessor, AFAIU. Why not call the directory "pyargprep", "pyargparsers" or such? Or may be "aclinic-output"? Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Mon, Jan 20, 2014 at 10:44 AM, Oleg Broytman <phd@phdru.name> wrote:
On Mon, Jan 20, 2014 at 04:07:51PM +0100, Stefan Krah <stefan@bytereef.org> wrote:
Bonus points for any other directory name that is more self-descriptive. ;)
Argument Clinic is a PyArg_Parse* preprocessor, AFAIU. Why not call the directory "pyargprep", "pyargparsers" or such? Or may be "aclinic-output"?
The fact that it emits PyArg_Parse*-using code is an implementation detail. It could easily change if we want since Argument Clinic abstracts out argument parsing entirely.
Stefan Krah <stefan@bytereef.org> wrote:
Larry Hastings <larry@hastings.org> wrote:
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h
+1 for this, 0 for the rest. Bonus points for any other directory name that is more self-descriptive. ;)
On second thought, I do find that having Modules/cjkcodecs Modules/clinic looks kind of weird. So I'm +1 for __clinic__, 0 on the rest. +2 for something more self-explanatory like: Modules/__arghandlers__ Modules/__autogen__ Stefan Krah
On Mon, Jan 20, 2014 at 3:05 AM, Larry Hastings <larry@hastings.org> wrote:
On 01/19/2014 08:29 AM, Ethan Furman wrote:
On 01/19/2014 03:32 AM, Georg Brandl wrote:
Am 19.01.2014 11:19, schrieb Larry Hastings:
Not kidding, my best idea so far is "foo.clinic.h.h",
Why not always put clinic into its own directory?
Modules/mathmodule.c -> Modules/clinic/mathmodule.c.h Modules/mathmodule.h -> Modules/clinic/mathmodule.h.h
At least that is consistent, allows easy exclusion in tools, and gets rid of the additional "clinic" in the filename.
+1
If AC will work with both .c and .h files. I think a separate directory is the way to go.
In theory, Argument Clinic works with any file for which it can iterate over by lines and recognize comments. It current supports C and Python files and automatically recognizes a bunch of extensions.
--------------------
Okay, I'm taking a poll. I will total your answers and take the result... strongly under advisement. ;-)
The rules: * The poll will be over in 48 hours, maybe sooner if a winner emerges early. * Please express your vote from -1 to +1. -0 and +0 will only be differentiated during a tiebreaker. * If you don't vote for a contestant, your vote will be assumed to be 0. * You may change your vote at any time while the poll is still running. * If you wish to nominate a new contestant, you may. Please give the contestant a name, and express how it would transform the filenames "foo.c" and "foo.h". I would strongly prefer that all transformations be expressable using str.format(transformation, filename="foo.c", basename="foo", extension=".c") .
The contestants so far:
Contestant 1: "Add .clinic.h"
foo.c -> foo.c.clinic.h foo.h -> foo.h.clinic.h
+0
Contestant 2: "Add .ac.h"
foo.c -> foo.c.ac.h foo.h -> foo.h.ac.h
-1
Contestant 3: "Add .clinic"
foo.c -> foo.c.clinic foo.h -> foo.h.clinic
+0
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h
+0
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h
+1
I didn't add a contestant for what Stefan Krah originally suggested ("foo.c -> foo.h") because it's not clear how this would handle "foo.h".
You'll notice the current behavior is no longer in the running,
And +1 to making a side file the default for ease of use.
On Mon, Jan 20, 2014 at 2:05 AM, Larry Hastings <larry@hastings.org> wrote:
Contestant 1: "Add .clinic.h"
foo.c -> foo.c.clinic.h foo.h -> foo.h.clinic.h
-0
Contestant 2: "Add .ac.h"
foo.c -> foo.c.ac.h foo.h -> foo.h.ac.h
-1
Contestant 3: "Add .clinic"
foo.c -> foo.c.clinic foo.h -> foo.h.clinic
-0
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h
+1
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h
+0 -- Zach
On 01/20/2014 12:05 AM, Larry Hastings wrote:
Contestant 1: "Add .clinic.h"
foo.c -> foo.c.clinic.h foo.h -> foo.h.clinic.h
-1
Contestant 2: "Add .ac.h"
foo.c -> foo.c.ac.h foo.h -> foo.h.ac.h
-1
Contestant 3: "Add .clinic"
foo.c -> foo.c.clinic foo.h -> foo.h.clinic
+0
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h foo.h -> clinic/foo.h.h
+0.5
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h
+1 -- ~Ethan~
On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote:
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h
This is cached output right? IOW, it can be regenerated if it's missing. If so, this seems like a nice parallel to __pycache__. It's mostly hidden until you want to go looking for it. +1 -Barry
On Mon, Jan 20, 2014 at 2:09 PM, Barry Warsaw <barry@python.org> wrote:
On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote:
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h
This is cached output right?
Yes, it's generated entirely based on data provided in original source file.
IOW, it can be regenerated if it's missing. If so, this seems like a nice parallel to __pycache__. It's mostly hidden until you want to go looking for it.
More-or-less. The key difference is you will most likely look at the generated file *once* to copy-and-paste the relevant macros to paste into your source file for use (e.g. the relevant MethodDef stuff). But it's a one-time thing that never has to be done again as long as you don't rename a function or method.
On 01/20/2014 11:46 AM, Brett Cannon wrote:
On Mon, Jan 20, 2014 at 2:09 PM, Barry Warsaw wrote:
On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote:
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h
This is cached output right?
Yes, it's generated entirely based on data provided in original source file.
IOW, it can be regenerated if it's missing. If so, this seems like a nice parallel to __pycache__. It's mostly hidden until you want to go looking for it.
More-or-less. The key difference is you will most likely look at the generated file *once* to copy-and-paste the relevant macros to paste into your source file for use (e.g. the relevant MethodDef stuff). But it's a one-time thing that never has to be done again as long as you don't rename a function or method.
Won't AC put those macros in the source file for you? -- ~Ethan~
Am 20.01.2014 21:05, schrieb Ethan Furman:
On 01/20/2014 11:46 AM, Brett Cannon wrote:
On Mon, Jan 20, 2014 at 2:09 PM, Barry Warsaw wrote:
On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote:
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h
This is cached output right?
Yes, it's generated entirely based on data provided in original source file.
IOW, it can be regenerated if it's missing. If so, this seems like a nice parallel to __pycache__. It's mostly hidden until you want to go looking for it.
More-or-less. The key difference is you will most likely look at the generated file *once* to copy-and-paste the relevant macros to paste into your source file for use (e.g. the relevant MethodDef stuff). But it's a one-time thing that never has to be done again as long as you don't rename a function or method.
Won't AC put those macros in the source file for you?
No, currently it wouldn't know where to look. And that's a good thing because AC never should modify anything not inbetween "clinic start generated code" and "clinic end generated code". But Larry has said that in the future the wohl PyMethodDef array might be generated by AC in a separate block (that you have to indicate in the file as well). Georg
On 01/20/2014 12:14 PM, Georg Brandl wrote:
Am 20.01.2014 21:05, schrieb Ethan Furman:
On 01/20/2014 11:46 AM, Brett Cannon wrote:
On Mon, Jan 20, 2014 at 2:09 PM, Barry Warsaw wrote:
On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote:
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h
This is cached output right?
Yes, it's generated entirely based on data provided in original source file.
IOW, it can be regenerated if it's missing. If so, this seems like a nice parallel to __pycache__. It's mostly hidden until you want to go looking for it.
More-or-less. The key difference is you will most likely look at the generated file *once* to copy-and-paste the relevant macros to paste into your source file for use (e.g. the relevant MethodDef stuff). But it's a one-time thing that never has to be done again as long as you don't rename a function or method.
Won't AC put those macros in the source file for you?
No, currently it wouldn't know where to look. And that's a good thing because AC never should modify anything not inbetween "clinic start generated code" and "clinic end generated code".
So, if I understand correctly, by moving into a sidefile approach, we will have go to a two-pass system? Once to ACify the file and run Argument Clinic on it, and then again to add in the macros? Is this basically the same as it was with the buffer approach? -- ~Ethan~
On 01/20/2014 01:47 PM, Ethan Furman wrote:
So, if I understand correctly, by moving into a sidefile approach, we will have go to a two-pass system? Once to ACify the file and run Argument Clinic on it, and then again to add in the macros?
Is this basically the same as it was with the buffer approach?
Let me paraphrase this to add context, to see if I understand your question correctly. When you add the Argument Clinic blob to a function, Argument Clinic generates some C code. That code contains a parsing function, an "impl" function (which you implement), and a macro to paste into the correct slot in the PyMethodDef structure. The name of the macro is full_name_of_function.upper() + "_METHODDEF". However, it can be inconvenient to guess what the actual macro name is, so most people fill out the structure, run clinic.py on the C file, then go hunting for the METHODDEF macro definition to get the name. This is what you refer to as "a two-pass system": edit the file, run Argument Clinic on it, then edit it to put the METHODDEF macro in the right spot. If that's what you meant, then: yes, and yes. It's possible to skip the second pass if you're comfortable guessing the generated name of the macro, but that's just one more thing for people to remember, and hunting for it is easier. And yes, whether it's original output or buffer or "clinic file" (I'm trying to deprecate the name "side file", it was a dumb idea), the destination Argument Clinic writes to doesn't dramatically alter what it writes. //arry/ p.s. Your saying "macros" threw me off, as there's only one macro.
On 01/20/2014 01:57 PM, Larry Hastings wrote:
If that's what you meant, then: yes, and yes. It's possible to skip the second pass if you're comfortable guessing the generated name of the macro, but that's just one more thing for people to remember, and hunting for it is easier. And yes, whether it's original output or buffer or "clinic file" (I'm trying to deprecate the name "side file", it was a dumb idea), the destination Argument Clinic writes to doesn't dramatically alter what it writes.
Okay, thanks. And I'm happy to call them clinic files. :) -- ~Ethan~
Am 20.01.2014 22:47, schrieb Ethan Furman:
Won't AC put those macros in the source file for you?
No, currently it wouldn't know where to look. And that's a good thing because AC never should modify anything not inbetween "clinic start generated code" and "clinic end generated code".
So, if I understand correctly, by moving into a sidefile approach, we will have go to a two-pass system? Once to ACify the file and run Argument Clinic on it, and then again to add in the macros?
No. It is completely the same as in the current all-in-one-file approach.
Is this basically the same as it was with the buffer approach?
It's the same as it always was. Georg
On 01/20/2014 11:09 AM, Barry Warsaw wrote:
On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote:
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h This is cached output right? IOW, it can be regenerated if it's missing. If so, this seems like a nice parallel to __pycache__. It's mostly hidden until you want to go looking for it.
+1
It's cached output. The difference to __pycache__ is that the output will be checked in, and is something you might ever want to examine. //arry/
participants (19)
-
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Chris Angelico -
Eric V. Smith -
Ethan Furman -
Georg Brandl -
Larry Hastings -
Meador Inge -
Nick Coghlan -
Oleg Broytman -
Richard Oudkerk -
Serhiy Storchaka -
Stefan Krah -
Steve Dower -
Tal Einat -
Terry Reedy -
Vajrasky Kok -
Zachary Ware