Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.1,2.2

"Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:
Guido> Modified Files: mmapmodule.c Log Message: Hacked for Win32 Guido> by Mark Hammond. Reformatted for 8-space tabs and fitted Guido> into 80-char lines by GvR. Can we change the 8-space-tab rule for all new C code that goes in? I know that we can't practically change existing code right now, but for new C code, I propose we use no tab characters, and we use a 4-space block indentation. -Barry

+1 for me too. It also brings all source files under the same guidelines (rather than seperate ones for .py and .c) Mark.

"MH" == Mark Hammond <mhammond@skippinet.com.au> writes:
MH> +1 for me too. It also brings all source files under the same MH> guidelines (rather than seperate ones for .py and .c) BTW, I further propose that if Guido lets me reformat the C code, that we freeze other checkins for the duration and I temporarily turn off the python-checkins email. That is, unless you guys /want/ to be bombarded with boatloads of useless diffs. :) -Barry

Hi! sigh :-(
bwarsaw@cnri.reston.va.us:
-1 for C reformatting. The 4 space intendation seesm reasonable for Python sources, but I disaggree for C code. C is not Python. Let me cite a very prominent member of the open source community (pasted from /usr/src/linux/Documentation/CodingStyle): Chapter 1: Indentation Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3. Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations. 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. In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning. Also the Python interpreter has no strong relationship with Linux kernel a agree with Linus on this topic. Python source code is another thing: Python identifiers are usually longer due to qualifiying and Python operands are often lists, tuples or the like, so lines contain more stuff. disliking-yet-another-white-space-discussion-ly y'rs - peter

Ironically, this statement is a strong argument for insisting on Python using real tab characters! "Clearly define" is upgraded to "used to define".
Yeah, right! int foo() { // one level for the privilege of being here. switch (bar) { // uh oh - running out of room... case WTF: // Oh no - if I use an "if" statement, // my code is "screwed"?? } }
disliking-yet-another-white-space-discussion-ly y'rs - peter
Like-death-and-taxes-ly y'rs - Mark.

Peter Funk wrote:
you're just guessing, right? (if you check, you'll find that the actual difference is very small. iirc, that's true for c, c++, java, python, tcl, and probably a few more languages. dunno about perl, though... :-) </F>

[Peter Funk]
-1 for C reformatting. The 4 space intendation seesm reasonable for Python sources, but I disaggree for C code. C is not Python.
Code is code. The project I work on professionally is a half million lines of C++, and 4-space indents are rigidly enforced -- works great. It makes just as much sense for C as for Python, and for all the same reasons. The one formal study I've seen on this showed that comprehension levels peaked at indent levels of 3 and 4, dropping off on both sides. However, tabs in C is one of Guido's endearing inconsistencies, and we don't want to lose the only two of those he has <wink> (his other is trying to avoid curly braces whenever possible in C, perhaps out of the same perverse sense of pride I used to take in avoiding redundant semicolons in Pascal <;{} wink>.

Hi!
Tim Peters:
Sigh... Well, if the Python-Interpreter C sources were indented with 4 spaces from the very beginning, I would have kept my mouth shut! But as we can't get the whole world to aggree on how to indent C-Sources, we should at least try to avoid the loss off energy and time, the debate on this topic will cause. So what's my point? IMO reformatting the C-sources wouldn't do us any favor. There will always be people, who like another indentation style more. The GNU software and the Linux kernel have set some standards within the open source community. These projects represent a reasonable fraction of programmers that may be potential contributors to other open source projects. So the only effect a reformatting from 8 to 4 space indents would be to disturb the "8-spacers" and causing endless discussions like this one. Period.
Aggreed. Best reagrds, Peter

"DA" == David Ascher <DavidA@ActiveState.com> writes:
DA> Heretic! DA> +1, FWIW =) I hereby offer to so untabify and reformat any C code in the standard distribution that Guido will approve of. -Barry

"Barry A. Warsaw" wrote:
Why not just leave new code formatted as it is (except maybe to bring the used TAB width to the standard 8 spaces used throughout the Python C source code) ? BTW, most of the new unicode stuff uses 4-space indents. Unfortunately, it mixes whitespace and tabs since Emacs c-mode doesn't do the python-mode magic yet (is there a way to turn it on ?). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

M.-A. Lemburg <mal@lemburg.com> wrote:
http://www.jwz.org/doc/tabs-vs-spaces.html contains some hints. </F>

Fredrik Lundh wrote:
Ah, cool. Thanks :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

"M" == M <mal@lemburg.com> writes:
M> BTW, most of the new unicode stuff uses 4-space indents. M> Unfortunately, it mixes whitespace and tabs since Emacs M> c-mode doesn't do the python-mode magic yet (is there a M> way to turn it on ?). (setq indent-tabs-mode nil) I could add that to the "python" style. And to zap all your existing tab characters: C-M-h M-x untabify RET -Barry

Actually, this one was formatted for 8-space indents but using 4-space tabs, so in my editor it looked like 16-space indents! Given that we don't want to change existing code, I'd prefer to stick with 1-tab 8-space indents. --Guido van Rossum (home page: http://www.python.org/~guido/)

+1 for me too. It also brings all source files under the same guidelines (rather than seperate ones for .py and .c) Mark.

"MH" == Mark Hammond <mhammond@skippinet.com.au> writes:
MH> +1 for me too. It also brings all source files under the same MH> guidelines (rather than seperate ones for .py and .c) BTW, I further propose that if Guido lets me reformat the C code, that we freeze other checkins for the duration and I temporarily turn off the python-checkins email. That is, unless you guys /want/ to be bombarded with boatloads of useless diffs. :) -Barry

Hi! sigh :-(
bwarsaw@cnri.reston.va.us:
-1 for C reformatting. The 4 space intendation seesm reasonable for Python sources, but I disaggree for C code. C is not Python. Let me cite a very prominent member of the open source community (pasted from /usr/src/linux/Documentation/CodingStyle): Chapter 1: Indentation Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3. Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations. 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. In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning. Also the Python interpreter has no strong relationship with Linux kernel a agree with Linus on this topic. Python source code is another thing: Python identifiers are usually longer due to qualifiying and Python operands are often lists, tuples or the like, so lines contain more stuff. disliking-yet-another-white-space-discussion-ly y'rs - peter

Ironically, this statement is a strong argument for insisting on Python using real tab characters! "Clearly define" is upgraded to "used to define".
Yeah, right! int foo() { // one level for the privilege of being here. switch (bar) { // uh oh - running out of room... case WTF: // Oh no - if I use an "if" statement, // my code is "screwed"?? } }
disliking-yet-another-white-space-discussion-ly y'rs - peter
Like-death-and-taxes-ly y'rs - Mark.

Peter Funk wrote:
you're just guessing, right? (if you check, you'll find that the actual difference is very small. iirc, that's true for c, c++, java, python, tcl, and probably a few more languages. dunno about perl, though... :-) </F>

[Peter Funk]
-1 for C reformatting. The 4 space intendation seesm reasonable for Python sources, but I disaggree for C code. C is not Python.
Code is code. The project I work on professionally is a half million lines of C++, and 4-space indents are rigidly enforced -- works great. It makes just as much sense for C as for Python, and for all the same reasons. The one formal study I've seen on this showed that comprehension levels peaked at indent levels of 3 and 4, dropping off on both sides. However, tabs in C is one of Guido's endearing inconsistencies, and we don't want to lose the only two of those he has <wink> (his other is trying to avoid curly braces whenever possible in C, perhaps out of the same perverse sense of pride I used to take in avoiding redundant semicolons in Pascal <;{} wink>.

Hi!
Tim Peters:
Sigh... Well, if the Python-Interpreter C sources were indented with 4 spaces from the very beginning, I would have kept my mouth shut! But as we can't get the whole world to aggree on how to indent C-Sources, we should at least try to avoid the loss off energy and time, the debate on this topic will cause. So what's my point? IMO reformatting the C-sources wouldn't do us any favor. There will always be people, who like another indentation style more. The GNU software and the Linux kernel have set some standards within the open source community. These projects represent a reasonable fraction of programmers that may be potential contributors to other open source projects. So the only effect a reformatting from 8 to 4 space indents would be to disturb the "8-spacers" and causing endless discussions like this one. Period.
Aggreed. Best reagrds, Peter

"DA" == David Ascher <DavidA@ActiveState.com> writes:
DA> Heretic! DA> +1, FWIW =) I hereby offer to so untabify and reformat any C code in the standard distribution that Guido will approve of. -Barry

"Barry A. Warsaw" wrote:
Why not just leave new code formatted as it is (except maybe to bring the used TAB width to the standard 8 spaces used throughout the Python C source code) ? BTW, most of the new unicode stuff uses 4-space indents. Unfortunately, it mixes whitespace and tabs since Emacs c-mode doesn't do the python-mode magic yet (is there a way to turn it on ?). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

M.-A. Lemburg <mal@lemburg.com> wrote:
http://www.jwz.org/doc/tabs-vs-spaces.html contains some hints. </F>

Fredrik Lundh wrote:
Ah, cool. Thanks :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

"M" == M <mal@lemburg.com> writes:
M> BTW, most of the new unicode stuff uses 4-space indents. M> Unfortunately, it mixes whitespace and tabs since Emacs M> c-mode doesn't do the python-mode magic yet (is there a M> way to turn it on ?). (setq indent-tabs-mode nil) I could add that to the "python" style. And to zap all your existing tab characters: C-M-h M-x untabify RET -Barry

Actually, this one was formatted for 8-space indents but using 4-space tabs, so in my editor it looked like 16-space indents! Given that we don't want to change existing code, I'd prefer to stick with 1-tab 8-space indents. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (9)
-
Barry A. Warsaw
-
bwarsaw@cnri.reston.va.us
-
David Ascher
-
Fredrik Lundh
-
Guido van Rossum
-
M.-A. Lemburg
-
Mark Hammond
-
pf@artcom-gmbh.de
-
Tim Peters