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. Thoughts? Chuck
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. Chuck
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
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". Of course, it is entirely up to you, the devs, on what to do for NumPy and SciPy, but that is what matplotlib is doing. Cheers! Ben Root
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 It's about finding the right balance, not about blindly running pep8 fixer tools. Cheers, Ralf
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
On Mon, Aug 26, 2013 at 4:26 PM, <josef.pktd@gmail.com> wrote:
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
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
participants (4)
-
Benjamin Root -
Charles R Harris -
josef.pktd＠gmail.com -
Ralf Gommers