python.vim indent plugin not pep8 compliant

[GoogleCodeExporter]

Hi,

The in-tree python indent plugin is not pep8 compliant

It would be nice if this was the case so vim would enforce good styling by 
default

http://www.python.org/dev/peps/pep-0008/

Original issue reported on code.google.com by l.bigonv...@gmail.com on 10 Dec 2012 at 10:30

[GoogleCodeExporter]

Hope to see it in vim 7.4 as there are some "The plan is to (1) improve Python 
support" news.

Original comment by ar...@maven.pl on 26 May 2013 at 8:25

[GoogleCodeExporter]

As of 
http://code.google.com/p/vim/source/diff?spec=svn173c9c860e42e2af31d598aa6924b99
d7e73bd1b&r=173c9c860e42e2af31d598aa6924b99d7e73bd1b&format=side&path=/runtime/f
tplugin/python.vim
the ftplugin is now PEP8 compliant.

Unfortunately, this is really annoying. I worked on a codebase that doesn't 
follow the PEP8 indent style. I wrote some code that looked right, broke 
everything, and am now angry.

There are times when it's OK to force an indent style on your users. GNU make 
doesn't accept anything other than hard tabs, so I'm fine with that ftplugin 
forcing hard tabs. Python becomes the 12th of 185 ftplugins to set a tab 
behavior but has no need to and breaks your editor for any codebase that isn't 
PEP-8 compliant already.

(Oh, by the way, that last changed time is clearly wrong.)

Original comment by lurayl on 20 Oct 2013 at 11:09

[GoogleCodeExporter]

> As of  
> 
http://code.google.com/p/vim/source/diff?spec=svn173c9c860e42e2af31d598aa6924b99
d7e73bd1b&r=173c9c860e42e2af31d598aa6924b99d7e73bd1b&format=side&path=/runtime/f
tplugin/python.vim
> the ftplugin is now PEP8 compliant.
> 
> Unfortunately, this is really annoying. I worked on a codebase that doesn't  
> follow the PEP8 indent style. I wrote some code that looked right, broke  
> everything, and am now angry.
> 
> There are times when it's OK to force an indent style on your users. GNU  
> make doesn't accept anything other than hard tabs, so I'm fine with that  
> ftplugin forcing hard tabs. Python becomes the 12th of 185 ftplugins to set  
> a tab behavior but has no need to and breaks your editor for any codebase  
> that isn't PEP-8 compliant already.

It does not force. It provides defaults. You have a bunch of ways to reset 
them: modelines, :au Filetype python, `set exrc` (better to use some plugin 
like localrc); there are also a bunch of plugins that can detect currently used 
coding style and adjust settings accordingly.

I do not think that having PEP8-compliant default is a bad thing. But grepping 
/usr/share/vim/vim74/ftplugin/*.vim reveals that it is not common to put 
“language default” coding styling definition into filetype plugins. Thus I 
would not vote for this change.

> 
> (Oh, by the way, that last changed time is clearly wrong.)

Original comment by zyx....@gmail.com on 20 Oct 2013 at 12:21

[GoogleCodeExporter]

> It does not force. It provides defaults. You have a bunch of ways to
> reset them: modelines, :au Filetype python, `set exrc` (better to use
> some plugin like localrc);

Don't forget the after/ directory.

> I do not think that having PEP8-compliant default is a bad thing. But
> grepping /usr/share/vim/vim74/ftplugin/*.vim reveals that it is not
> common to put “language default” coding styling definition into filetype
> plugins.

I think that correlates more to the fact that most languages don't have
a self or community imposed coding style.  Python, make, cobol, Go, and
Java are a few off-hand that I can think of which do.

Original comment by vega.james@gmail.com on 20 Oct 2013 at 1:18

[GoogleCodeExporter]

> I think that correlates more to the fact that most languages don't have
> a self or community imposed coding style.  Python, make, cobol, Go, and
> Java are a few off-hand that I can think of which do.

Still java does not have such settings. Cobol only provides default for 
textwidth and expandtab, but not shiftwidth or [soft]tabstop. For make (and 
ebuild) AFAIK you *must* use tabs, this is not the case for python.

Original comment by zyx....@gmail.com on 20 Oct 2013 at 2:37

[GoogleCodeExporter]

Closing. Please note, that if you have problems with an included runtime file, 
first bring the issue to the maintainer of the file, before asking here.

Original comment by chrisbr...@googlemail.com on 30 Sep 2014 at 6:57

• Changed state: Fixed