YJL

" Vim filetype plugin file
" Language:   python
" Maintainer: Johannes Zellner <johannes@zellner.org>
" Last Change:        2014 Feb 09
" Last Change By Johannes: Wed, 21 Apr 2004 13:13:08 CEST

" [snip]

" As suggested by PEP8.
setlocal expandtab shiftwidth=4 softtabstop=4 tabstop=8

1   My thoughts

This forces PEP8 on users and I strongly disagree with this change. No, I don’t use 4-space but 2-space. But that’s not the point even I was a 4-space, I’d not agree with this kind of change.

First of all, PEP8 is not a standard nor a syntax, it’s purely a coding style and an option. Just a week or two ago, someone had heating discussion with me about 4 or 2, and why I don’t follow PEP8 entirely.

The most important thing is the consistence of coding style. Not the 4 or 2, or even 6¹. When you contribute to a project, you need to study the style before coding.

In Python, the indentation is important, but not the number of, and, what kind of indentation. Either 2 or 4, either space or tab, they will all conforms to the syntax, which is the standard, not PEP8.

To give you an example why I don’t like this kind of change, read the following from Chromium Python Style Guidelines:

The Google Python Style guide is the official python style guide for Chromium OS original code. Note that we deviate from that guide in two ways (in order to match the internal Google Python Style guide):

• Indentation: use 2, not 4, spaces

• Naming: Functions and Method names use CapWords() style, not lower_with_under()

  The only exception to this rule is the main() function — we do not use Main()

Google Python Style guide follows PEP8, and Chromium project follows it, but with some differences.

My point here is not Google or Chromium, but people need to understand the differences of standards and guidelines, and the latter should not be considered, applied, and forced onto every projects.

Please allow me to quote a few from PEP8 in case you haven’t actually read it but only blindly follow it:

Many projects have their own coding style guidelines. In the event of any conflicts, such project-specific guides take precedence for that project.

---

A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.

But most importantly: know when to be inconsistent — sometimes the style guide just doesn’t apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don’t hesitate to ask!

In particular: do not break backwards compatibility just to comply with this PEP!

Frankly, I don’t think many people actually “follow” it in that sense, it’s just other people talk about it, they thoughtlessly brainwash themselves and then brainwash others without knowing anything particularly.

Just be on safe side, if you really haven’t read it, read its title carefully:

Style Guide for Python Code

‘nuff said, right? This should be tl;dr instead of this stinky long section.

So, should you follow PEP8 to every bit? If you don’t have time to write your guideline for others to follow, then it’s not a bad idea.

For me, I’d tell people to check with pep8 but --ignore=E111,E121 for 2-space indentation. And if you can’t follow it or can’t even tell I have consistent coding style, I honestly don’t know what to say to you.

2   Resolution

I use .vim/after/ftplugin/python.vim to override back to my settings:

" fixing forced PEP8, which introduced by Vim 7.4 ftplugin/python.vim
setlocal shiftwidth=2
setlocal softtabstop=2

---

[1]	Okay, I have never seen 6-space, if you happen to see one, please leave me a link. I’d love to check it out.