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
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 directory?
+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:
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
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
On Mon, 20 Jan 2014 00:05:16 -0800
Larry Hastings la...@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
On 20 January 2014 21:14, Serhiy Storchaka storch...@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
20.01.14 15:03, Nick Coghlan написав(ла):
On 20 January 2014 21:14, Serhiy Storchaka storch...@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
On Mon, Jan 20, 2014 at 2:05 AM, Larry Hastings la...@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 -
Larry Hastings la...@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. ;)
Stefan Krah
On Mon, Jan 20, 2014 at 3:05 AM, Larry Hastings la...@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
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
On Mon, Jan 20, 2014 at 2:05 AM, Larry Hastings la...@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 -
On Mon, Jan 20, 2014 at 04:07:51PM +0100, Stefan Krah ste...@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
On Mon, Jan 20, 2014 at 10:44 AM, Oleg Broytman p...@phdru.name wrote:
On Mon, Jan 20, 2014 at 04:07:51PM +0100, Stefan Krah ste...@bytereef.org
wrote:
Bonus points for any other directory name that is
more self-descriptive. ;)
Argument Clinic is a PyArg_Parse* preprocessor, AFAIU. Why
On Mon, Jan 20, 2014 at 10:05 AM, Larry Hastings la...@hastings.org 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
Stefan Krah ste...@bytereef.org wrote:
Larry Hastings la...@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.
Am 20.01.2014 14:31, schrieb Serhiy Storchaka:
20.01.14 15:03, Nick Coghlan написав(ла):
On 20 January 2014 21:14, Serhiy Storchaka storch...@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 -
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
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__.
On Mon, Jan 20, 2014 at 2:09 PM, Barry Warsaw ba...@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
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.c.h
foo.h -
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
On 01/20/2014 05:03 AM, Nick Coghlan wrote:
On 20 January 2014 21:14, Serhiy Storchaka storch...@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
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 storch...@gmail.com wrote:
20.01.14 10:05, Larry Hastings написав(ла):
Contestant 4: Put in clinic directory, add .h
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
On 21 Jan 2014 08:20, Serhiy Storchaka storch...@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 storch...@gmail.com wrote:
20.01.14 10:05, Larry
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,
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
On 01/18/2014 10:36 PM, Nick Coghlan wrote:
On 19 January 2014 10:44, Steve Dower steve.do...@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
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.do...@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
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 steve.do...@microsoft.com wrote:
Visual Studio will try to compile them if they end with .c, though this can
be disabled
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.
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 storch...@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
On 18 Jan 2014 19:08, Chris Angelico ros...@gmail.com wrote:
On Sat, Jan 18, 2014 at 8:02 PM, Serhiy Storchaka storch...@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
Serhiy Storchaka storch...@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
On Sat, 18 Jan 2014 18:06:06 +0100
Stefan Krah ste...@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
Antoine Pitrou solip...@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. 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 ste...@bytereef.org wrote:
Antoine Pitrou solip...@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
Antoine Pitrou solip...@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
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
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
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
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.
___
18.01.14 19:09, Antoine Pitrou написав(ла):
On Sat, 18 Jan 2014 18:06:06 +0100
Stefan Krah ste...@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
On Sat, Jan 18, 2014 at 12:10 PM, Serhiy Storchaka storch...@gmail.com wrote:
18.01.14 19:09, Antoine Pitrou написав(ла):
On Sat, 18 Jan 2014 18:06:06 +0100
Stefan Krah ste...@bytereef.org wrote:
I'd rather see memoryview.h than memoryview.clinic.c.
Or, if this collides with Include/*,
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)
Serhiy Storchaka storch...@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
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
@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
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
On 19 January 2014 10:44, Steve Dower steve.do...@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
61 matches
Mail list logo
