Hi! sigh :-(
"MH" == Mark Hammond
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)
bwarsaw@cnri.reston.va.us:
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. :)
-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