Hello, On Mon, 15 Jul 2013 15:17:24 +0100 Neil Williams <codeh...@debian.org> wrote:
> At LCE13, we proposed to check code against PEP8 > (http://cards.linaro.org/browse/LAVA-485) prior to merges and the > initial thought was that we could just rely on PyCharm to show the > code as "all green" to achieve PEP8 compatibility. > > Turns out that PyCharm doesn't restrict itself to PEP8 and can > override PEP8 with project-specific settings in some areas (typically > line length). > > Line length is actually a bit awkward in places and I've been using > the default PyCharm length of 120 whilst PEP8 advises 79. To keep the > code readable, this could involve a number of new single-use > sub-routines to reduce the indenting. Is this worth doing? If not, we > can look at a project-specific [pep8] setting in setup.py. Line length was always my concern during previous codestyle discussion in Infra team. I agree that ~80 char limit feel so last-century. Next terminal line length is 132, and that's what I'd rather use. I cannot say that this proposal was support by everyone. I obviously try to stick with existing codestyle when hacking existing code (including average line length), and writing new small tools you usually don't get into limits, so I didn't hit into issues with line limits lately, though I agree when that issue hits, squeezing the Python code into this (arbitrary by nowadays) limitation is awkward. So, count my vote for extending line size limit. Or if not, I can keep up with 79 chars too. But I'm sure there's no need to warp LAVA code if it already uses longer lines. > > Other tools for PEP8 include pep8 itself, pylint and pychecker. > > The command line pep8 has various false positives and false negatives > in it's bug history, so we may all have to run the same version and > then mandate that version when others test the code too. Reading this and other comments, I'm a bit surprised that such issues exist - I don't remember hitting those, even though used python codestyle checks in different projects. After all, PEP8 was created 05-Jul-2001 and didn't change since then (if it did, it would be different PEP), so any variations would be attributed to allowed variations and underspecification in PEP8, subject to tool's user-adjustable configuration (and bugs, yeah, but those would be fixed by now?). All in all, good practice is to just integrate codestyle checks as part of project configuration, so one can just run "make style" or "./check-style", and get consistent result, with underlying implementation using specific set of options (and specific version of a tool is that's really an issue). [] -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog _______________________________________________ linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
