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
On Sat, Jan 18, 2014 at 8:02 PM, Serhiy Storchaka 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
On 18 Jan 2014 19:08, "Chris Angelico" wrote:
>
> On Sat, Jan 18, 2014 at 8:02 PM, Serhiy Storchaka
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 th
Serhiy Storchaka 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
On 1/18/2014 11:24 AM, Stefan Krah wrote:
> Serhiy Storchaka 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.
Or, if this collides with Include/*, one of the following:
memoryview_func.h // public functions
memoryview_if.h // public interface
Stefan Krah
___
Python-Dev mailing list
Python-Dev
On Sat, 18 Jan 2014 18:06:06 +0100
Stefan Krah 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 s
Antoine Pitrou wrote:
> Objects/memoryview.clinic.h should be fine.
Last attempt:
Objects/memoryview.api.h
That is more neutral and describes what the file contains. IOW, it's easier to
ignore the name (which is good in this case).
Stefan Krah
___
On Sat, 18 Jan 2014 18:18:49 +0100
Stefan Krah wrote:
> Antoine Pitrou 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
Antoine Pitrou 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
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 sug
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
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 v
18.01.14 19:39, Stefan Krah написав(ла):
Right. Objects/memoryview.ac.h perhaps? I sort of dislike reading full words
in filename extensions.
.ac is well known suffix of autoconf related files. And tail .h has same
disadvantages as .c.
___
Pytho
18.01.14 19:09, Antoine Pitrou написав(ла):
On Sat, 18 Jan 2014 18:06:06 +0100
Stefan Krah 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 interf
On Sat, Jan 18, 2014 at 12:10 PM, Serhiy Storchaka wrote:
> 18.01.14 19:09, Antoine Pitrou написав(ла):
>
>> On Sat, 18 Jan 2014 18:06:06 +0100
>> Stefan Krah wrote:
I'd rather see memoryview.h than memoryview.clinic.c.
>>>
>>>
>>> Or, if this collides with Include/*, one of the followi
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) tha
Serhiy Storchaka 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
___
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__.
t;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
ge
On 01/18/2014 10:49 AM, Larry Hastings wrote:
Later in the thread someone suggests that ".h" would be a better ending; I'm
willing to consider that.
I'll cast a vote for .clinic.h. :)
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
ht
On 19 January 2014 10:44, Steve Dower 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
On 01/18/2014 10:36 PM, Nick Coghlan wrote:
On 19 January 2014 10:44, Steve Dower 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 c
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 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
>>>
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
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 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
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/string
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
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 dir
+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.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https
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.
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@p
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.
On Mon, 20 Jan 2014 00:05:16 -0800
Larry Hastings 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 clin
On 20 January 2014 21:14, Serhiy Storchaka 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
20.01.14 15:03, Nick Coghlan написав(ла):
On 20 January 2014 21:14, Serhiy Storchaka 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 origin
On Mon, Jan 20, 2014 at 2:05 AM, Larry Hastings 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 -
Larry Hastings 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. ;)
Stefan Krah
___
On Mon, Jan 20, 2014 at 3:05 AM, Larry Hastings 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 it
>
> 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
>
> Contes
On Mon, Jan 20, 2014 at 2:05 AM, Larry Hastings 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.
On Mon, Jan 20, 2014 at 04:07:51PM +0100, Stefan Krah
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"?
O
On Mon, Jan 20, 2014 at 10:44 AM, Oleg Broytman wrote:
> On Mon, Jan 20, 2014 at 04:07:51PM +0100, Stefan Krah
> 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 "
On Mon, Jan 20, 2014 at 10:05 AM, Larry Hastings wrote:
>
> Okay, I'm taking a poll. I will total your answers and take the result...
> strongly under advisement. ;-)
+1 for #5, +0.5 for #4, -1 for the rest.
___
Python-Dev mailing list
Python-Dev@pytho
Stefan Krah wrote:
> Larry Hastings 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 though
Am 20.01.2014 14:31, schrieb Serhiy Storchaka:
> 20.01.14 15:03, Nick Coghlan написав(ла):
>> On 20 January 2014 21:14, Serhiy Storchaka wrote:
>>> 20.01.14 10:05, Larry Hastings написав(ла):
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h
foo.
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.
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 __pycac
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 enti
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?
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.
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 a
On 01/20/2014 05:03 AM, Nick Coghlan wrote:
On 20 January 2014 21:14, Serhiy Storchaka 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 origi
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,
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"
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
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 wrote:
20.01.14 10:05, Larry Hastings написав(ла):
Contestant 4: "Put in clinic directory, add .h"
foo.c -> cli
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
On 21 Jan 2014 08:20, "Serhiy Storchaka" 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 wrote:
>
> 20.01.14 10:05, Larry Hasting
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, whet
Am 20.01.2014 09:15, schrieb Georg Brandl:
>> 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.)
Make that +0.
Georg
__
20.01.14 13:14, Serhiy Storchaka написав(ла):
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.
__
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
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
63 matches
Mail list logo
