Fred L. Drake, Jr. writes:

Guido has grudgingly granted that new code in the "New style" is acceptable, mostly because many people complain that "Guido style" causes too much code to get scrunched up on the right margin.

I am reminded of Linus Torvalds comments on this subject (see /usr/src/linux/Documentation/CodingStyle): Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

Fred L. Drake, Jr. writes:

The catch, of course, is Python/cevel.c, where breaking it up can hurt performance. People scream when you do things like that....

Quoting again from the same source: Use helper functions with descriptive names (you can ask the compiler to in-line them if you think it's performance-critical, and it will probably do a better job of it that you would have done). But I should have pointed out that I was quoting the great Linus mostly for entertainment/cultural value, and was not really trying to add fuel to the fire. In other words, a message that I thought was amusing, but probably shouldn't have sent ;-)

Fred wrote:

I understood the intent; I think he's really got a point. There are a few places in Python where it would really help to break things up!

if that's what you want, maybe you could start by putting the INLINE stuff back again? <halfwink> (if C/C++ compatibility is a problem, put it inside a cplusplus ifdef, and mark it as "for internal use only. don't use inline on public interfaces") </F>

Fred wrote:

...

if that's what you want, maybe you could start by putting the INLINE stuff back again? <halfwink>

I could not see the value in the inline stuff that configure was setting up, and still don't.

the INLINE stuff guarantees that "inline" is defined to be whatever directive the compiler uses for explicit inlining. quoting the autoconf docs: If the C compiler supports the keyword inline, do nothing. Otherwise define inline to __inline__ or __inline if it accepts one of those, otherwise define inline to be empty as a result, you can always use "inline" in your code, and have it do the right thing on all compilers that support ex- plicit inlining (all modern C compilers, in practice). ::: to deal with people compiling Python with a C compiler, but linking it with a C++ compiler, the config.h.in file could be written as: /* Define "inline" to be whatever the C compiler calls it. To avoid problems when mixing C and C++, make sure to only use "inline" for internal interfaces. */ #ifndef __cplusplus #undef inline #endif </F>

2. Guido repeats that he prefers old-style (but in a wishy-washy way that leaves it uncertain (*)).

OK, since a pronouncement is obviously needed, here goes: Python C source code should be indented using tabs only. Exceptions: (1) If 3rd party code is already written using a different style, it can stay that way, especially if it's a large volume that would be hard to reformat. But only if it is consistent within a file or set of files (e.g. a 3rd party patch will have to conform to the prevailing style in the patched file). (2) Occasionally (e.g. in ceval.c) there is code that's very deeply nested. I will allow 4-space indents for the innermost nesting levels here. Other C whitespace nits: - Always place spaces around assignment operators, comparisons, &&, ||. - No space between function name and left parenthesis. - Always a space between a keyword ('if', 'for' etc.) and left paren. - No space inside parentheses, brackets etc. - No space before a comma or semicolon. - Always a space after a comma (and semicolon, if not at end of line). - Use ``return x;'' instead of ``return(x)''. --Guido van Rossum (home page: http://www.python.org/~guido/)

Fred L. Drake, Jr. writes:

Guido has grudgingly granted that new code in the "New style" is acceptable, mostly because many people complain that "Guido style" causes too much code to get scrunched up on the right margin.

I am reminded of Linus Torvalds comments on this subject (see /usr/src/linux/Documentation/CodingStyle): Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

Fred L. Drake, Jr. writes:

The catch, of course, is Python/cevel.c, where breaking it up can hurt performance. People scream when you do things like that....

Quoting again from the same source: Use helper functions with descriptive names (you can ask the compiler to in-line them if you think it's performance-critical, and it will probably do a better job of it that you would have done). But I should have pointed out that I was quoting the great Linus mostly for entertainment/cultural value, and was not really trying to add fuel to the fire. In other words, a message that I thought was amusing, but probably shouldn't have sent ;-)

Fred wrote:

I understood the intent; I think he's really got a point. There are a few places in Python where it would really help to break things up!

if that's what you want, maybe you could start by putting the INLINE stuff back again? <halfwink> (if C/C++ compatibility is a problem, put it inside a cplusplus ifdef, and mark it as "for internal use only. don't use inline on public interfaces") </F>

Fred wrote:

...

if that's what you want, maybe you could start by putting the INLINE stuff back again? <halfwink>

I could not see the value in the inline stuff that configure was setting up, and still don't.

the INLINE stuff guarantees that "inline" is defined to be whatever directive the compiler uses for explicit inlining. quoting the autoconf docs: If the C compiler supports the keyword inline, do nothing. Otherwise define inline to __inline__ or __inline if it accepts one of those, otherwise define inline to be empty as a result, you can always use "inline" in your code, and have it do the right thing on all compilers that support ex- plicit inlining (all modern C compilers, in practice). ::: to deal with people compiling Python with a C compiler, but linking it with a C++ compiler, the config.h.in file could be written as: /* Define "inline" to be whatever the C compiler calls it. To avoid problems when mixing C and C++, make sure to only use "inline" for internal interfaces. */ #ifndef __cplusplus #undef inline #endif </F>

2. Guido repeats that he prefers old-style (but in a wishy-washy way that leaves it uncertain (*)).

OK, since a pronouncement is obviously needed, here goes: Python C source code should be indented using tabs only. Exceptions: (1) If 3rd party code is already written using a different style, it can stay that way, especially if it's a large volume that would be hard to reformat. But only if it is consistent within a file or set of files (e.g. a 3rd party patch will have to conform to the prevailing style in the patched file). (2) Occasionally (e.g. in ceval.c) there is code that's very deeply nested. I will allow 4-space indents for the innermost nesting levels here. Other C whitespace nits: - Always place spaces around assignment operators, comparisons, &&, ||. - No space between function name and left parenthesis. - Always a space between a keyword ('if', 'for' etc.) and left paren. - No space inside parentheses, brackets etc. - No space before a comma or semicolon. - Always a space after a comma (and semicolon, if not at end of line). - Use ``return x;'' instead of ``return(x)''. --Guido van Rossum (home page: http://www.python.org/~guido/)