On Mon, Aug 26, 2013 at 4:26 PM, <[email protected]> wrote: > > > > On Mon, Aug 26, 2013 at 12:19 PM, Ralf Gommers <[email protected]>wrote: > >> >> >> >> On Mon, Aug 26, 2013 at 3:49 PM, Benjamin Root <[email protected]> wrote: >> >>> >>> On Mon, Aug 26, 2013 at 11:01 AM, Ralf Gommers >>> <[email protected]>wrote: >>> >>>> >>>> >>>> >>>> On Sun, Aug 18, 2013 at 6:36 PM, Charles R Harris < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Sun, Aug 18, 2013 at 12:17 PM, Charles R Harris < >>>>> [email protected]> 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
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
