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

Georg Brandl g.brandl at gmx.net
Wed May 31 16:14:45 CEST 2006


Martin Blais wrote:
> 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?

The consensus at NFS was that it also applies to newly written C files.
I did update the PEP, but that doesn't seem to have propagated to the
web site yet.

> 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.

That's bad, but is the way the code was written and should not be
changed for the sake of changing.

> 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
> effect?

AFAIK not before Python 3.0 since it would unnecessarily break,
for instance, svn blame and make merging more difficult.

[...]

> 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.

For the future (=Py3k), I think this would be nice.


Georg



More information about the Python-Dev mailing list