On Mon, Aug 26, 2013 at 12:19 PM, Ralf Gommers <ralf.gomm...@gmail.com>wrote:
> > > > On Mon, Aug 26, 2013 at 3:49 PM, Benjamin Root <ben.r...@ou.edu> wrote: > >> >> On Mon, Aug 26, 2013 at 11:01 AM, Ralf Gommers <ralf.gomm...@gmail.com>wrote: >> >>> >>> >>> >>> On Sun, Aug 18, 2013 at 6:36 PM, Charles R Harris < >>> charlesr.har...@gmail.com> wrote: >>> >>>> >>>> >>>> >>>> On Sun, Aug 18, 2013 at 12:17 PM, Charles R Harris < >>>> charlesr.har...@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 > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
