[Numpy-discussion] 1.8.0 branch reminder

[Ralf Gommers]

On Mon, Aug 26, 2013 at 3:49 PM, Benjamin Root <ben.root at ou.edu> wrote:

>
> On Mon, Aug 26, 2013 at 11:01 AM, Ralf Gommers <ralf.gommers at gmail.com>wrote:
>
>>
>>
>>
>> On Sun, Aug 18, 2013 at 6:36 PM, Charles R Harris <
>> charlesr.harris at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Sun, Aug 18, 2013 at 12:17 PM, Charles R Harris <
>>> charlesr.harris at 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

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

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130826/40577ac9/attachment.html>