[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