[Numpy-discussion] 1.8.0 branch reminder

josef.pktd@gmai... josef.pktd@gmai...
Mon Aug 26 11:26:11 CDT 2013


On Mon, Aug 26, 2013 at 12:19 PM, Ralf Gommers <ralf.gommers@gmail.com>wrote:

>
>
>
> On Mon, Aug 26, 2013 at 3:49 PM, Benjamin Root <ben.root@ou.edu> wrote:
>
>>
>> On Mon, Aug 26, 2013 at 11:01 AM, Ralf Gommers <ralf.gommers@gmail.com>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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20130826/369e86bf/attachment-0001.html 


More information about the NumPy-Discussion mailing list