On Mon, Aug 26, 2013 at 11:01 AM, Ralf Gommers wrote:

On Sun, Aug 18, 2013 at 6:36 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:

...

On Sun, Aug 18, 2013 at 12:17 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:

...

Just a reminder that 1.8.0 will be branched tonight. I've put up a big STY: PR https://github.com/numpy/numpy/pull/3635 that removes trailing whitespace and fixes spacing after commas. I would like to apply before the branch, but it may cause merge difficulties down the line. I'd like feedback on that option.

I've also run autopep8 on the code and it does a nice job of cleaning up things. It gets a little lost in deeply nested lists, but there aren't too many of those. By default it doesn't fix spaces about operator (it seems). I can apply that also if there is interest in doing so.

Depends on how many lines of code it touches. For scipy we decided not to do this, because it would make "git blame" pretty much useless.

Ralf

At some point, you just have to bite the bullet. Matplotlib has been doing pep8 work for about a year now. We adopted very specific rules on how that work was to be done (make pep8 only PRs, each pep8 PR would be for at most one module at a time, etc). Yes, it does look like NelleV has taken over the project, but the trade-off is readability. We even discovered a non-trivial number of bugs this way. For a core library like NumPy that has lots of very obscure-looking code that almost never gets changed, avoiding PEP8 is problematic because it always becomes "Somebody else's problem". Of course, it is entirely up to you, the devs, on what to do for NumPy and SciPy, but that is what matplotlib is doing. Cheers! Ben Root

On Mon, Aug 26, 2013 at 12:19 PM, Ralf Gommers wrote:

On Mon, Aug 26, 2013 at 3:49 PM, Benjamin Root wrote:

...

On Mon, Aug 26, 2013 at 11:01 AM, Ralf Gommers wrote:

...

On Sun, Aug 18, 2013 at 6:36 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:

...

On Sun, Aug 18, 2013 at 12:17 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:

...

Just a reminder that 1.8.0 will be branched tonight. I've put up a big STY: PR https://github.com/numpy/numpy/pull/3635 that removes trailing whitespace and fixes spacing after commas. I would like to apply before the branch, but it may cause merge difficulties down the line. I'd like feedback on that option.

I've also run autopep8 on the code and it does a nice job of cleaning up things. It gets a little lost in deeply nested lists, but there aren't too many of those. By default it doesn't fix spaces about operator (it seems). I can apply that also if there is interest in doing so.

Depends on how many lines of code it touches. For scipy we decided not to do this, because it would make "git blame" pretty much useless.

Ralf

At some point, you just have to bite the bullet. Matplotlib has been doing pep8 work for about a year now. We adopted very specific rules on how that work was to be done (make pep8 only PRs, each pep8 PR would be for at most one module at a time, etc). Yes, it does look like NelleV has taken over the project, but the trade-off is readability. We even discovered a non-trivial number of bugs this way. For a core library like NumPy that has lots of very obscure-looking code that almost never gets changed, avoiding PEP8 is problematic because it always becomes "Somebody else's problem".

We've been doing a lot of PEP8 cleanups in scipy - there's even ``tox -e pep8`` with a limited number of exceptions. And Chuck has just done a lot of cleanup for numpy, which is quite useful. So it's definitely not just someone else's problem.

The question was specifically about spaces around operators, which doesn't necessarily even make things look better (even apart from destroying history). This:

a*x[0] + b*x[1] + c*x[2]**2

look imho better than if you'd "fix" it like:

a * x[0] + b * x[1] + c * x[2] ** 2

that's not pep-8 (anymore) http://www.python.org/dev/peps/pep-0008/#other-recommendations Josef

It's about finding the right balance, not about blindly running pep8 fixer tools.

Cheers, Ralf

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion