[Python-Dev] A can of worms... (does Python C code have a new C style?)

Martin Blais blais at furius.ca
Wed May 31 13:02:02 CEST 2006

Hi all

I'd like to know what the policy is on the source code indentation for
C code in the interpreter.  At the Need-for-Speed sprints, there was
consensus that there is a "new" indentation for style for the Python C
source files, with

* indentation (emacs: c-basic-offset): 4 chars
* no tabs (so tab-width does not matter)
* 79 chars max for lines (I think)

(Correct me if any of this is wrong.)  I cannot find where this
discussion comes from, PEP 7 seems to imply that the new style only
applies to Python 3k.  Is this correct?

However, people were maintaining the existing styles when they were
editing part of existing files (I setup emacs users with two c-styles,
"python" and "python-new", so they could switch per-file), but using
the new guidelines for new files.  I look at the source code, and
there is a bit of a mix of the two styles in some places.

Is there a "grand plan" to convert all the code at once at some point?
If not, how is it that these new guidelines are supposed to take

I could easily contribute to the vaccuuming here, by writing a script
that will run emacs in batch mode on all the C code with the
appropriate new style to do the following for each C file present:

* re-indent the entire file according to the new guidelines
* convert all the tabs to whitespace
* delete trailing whitespace on all lines
* remove those pesky CR if there are any
* (anything else you'd like that's easily done from emacs?)

The problem is that if someone was to check-in the result of this
automation there would be a huge wave of complaints from merge
conflicts for people who have a checkouts with lots of uncommitted
changes.  I don't see any painless way to do this.  To ease the pain,
however, it could be done at a fixed time, giving everyone a wide
margin of chance to commit beforehand.

In addition, should this be applied, we should probably create a
Subversion hook that will automatically convert tabs to spaces, or
fails the commit if the files don't comply.

I realize this is potentially opening a can of worms, but on the one
hand I'd like to know what's the low-down on the indentation, and on
the other hand I won't spend a second on this if this is only going to
lead to trouble.

Then again, maybe I misunderstood and the new rules apply only to
Python 3k, in which case, well, press delete and move on.


More information about the Python-Dev mailing list