[Numpy-discussion] 1.8.0 branch reminder

[Ralf Gommers]

On Mon, Aug 26, 2013 at 4:26 PM, <josef.pktd at gmail.com> wrote:

>
>
>
> On Mon, Aug 26, 2013 at 12:19 PM, Ralf Gommers <ralf.gommers at gmail.com>wrote:
>
>>
>>
>>
>> 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
>>
>
> that's not pep-8 (anymore)
> http://www.python.org/dev/peps/pep-0008/#other-recommendations
>

Thanks for pointing that out. Unfortunately it still is exactly what
autopep8 will do:

$ cat tmp.py
a*x[0] + b*x[1] + c*x[2]**2
a * x[0] + b * x[1] + c * x[2] ** 2

$ autopep8 -d tmp.py
--- original/tmp.py
+++ fixed/tmp.py
@@ -1,2 +1,2 @@
-a*x[0] + b*x[1] + c*x[2]**2
 a * x[0] + b * x[1] + c * x[2] ** 2
+a * x[0] + b * x[1] + c * x[2] ** 2

Maybe you can get it to ignore certain operators, but I doubt it will be
smart enough to follow the PEP8 recommendations on spacing dependent on
operator precedence.

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