Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Pep8 on the axes module #1417

Closed
wants to merge 2 commits into from

6 participants

@NelleV
Collaborator

Reopening this PR with rebased code.

Thanks,
N

@dmcdougall
Collaborator

Currently, there's no way for me to provide inline comments as feedback on this pull request. GitHub is hiding the diff because it is big. I have emailed support to try and get this resolved. It is pretty crucial that other developers and contributors are able to provide inline feedback on PEP8 pull requests. I will touch base again when GitHub support reaches out to me.

@NelleV
Collaborator

I can try to break this into different PR if github doesn't react "quickly".

@efiring
Owner
@WeatherGod
Collaborator
@dmcdougall
Collaborator

From Ben Lavendar at GitHub support:

Damon,

Sorry, but we max out diffs at 100k per file. This diff is 224k.

You'll need to break it into smaller commits if you want to do line-by-line commenting.
Sorry about that.
@ivanov
Collaborator

so I know I'm really late to the party, but to me this is a pretty big sign that we shouldn't even be doing this in the first place. In most of the changes, I don't see a clear benefit. For example: removing the trailing \ on line continuations. I think style changes are fine as they are incorporated in actual changes to the code, but having purely stylistic changes all through the code base (and in tons of separate commits throughout the codebase) is the wrong way to go. (edited, see my next comment below)

There was one big commit to IPython that went through and removed a whole bunch of trailing whitespace. I have now bumped into the commit several times when trying to figure out when particular lines of code were last changed, except that it wasn't a functional or informative changeset, just an annoyance to hope over and makes git blame much less effective at trying to track down bugs. (Now, for that particular case, it turns out there's git blame -w which ignores whitespace, but there won't be such a friendly "ignore PEP8" changes flag.

@NelleV
Collaborator

I'll wait for @WeatherGod to finish the refactoring: this file really needs one, and the pep8 changes will be much much easier when splitted. If you need help with it, give me a shout.

@ivanov I'm tired and I've been working quite hard on those patches so I'm reacting quite quite strongly here:

First, I've been working on this for more than 2 months now, so indeed, your concern comes a bit late, specially as I asked whether those changes were welcome, how to proceed...

Why do I pep8 changes? Like many developpers, I don't work on non pep8 compliant code because non pep8 compliant distract me from the real problems. More and more people in the scientific community will not contribute to a project which is not pep8 (one of IPython's core dev once even told me he refused to review non pep8 compliant code). I initially started looking at the codebase to fix a bug. It turned out that the tests didn't run on python2.6: the reason was a typo in the code, something that is easily spotted when running flake8 on the code (which I automatically do, each time I save a file in vim). That's what pushed me to go forward with the patches.

Why should matplotlib be pep8-compliant?
1. Make the code more readable
2. Code style conventions allows to smoothen style differences between developpers, hence allowing everyone to get in the code faster (who has not reindented a C++ file completely once in his life?).
3. Those changes allowed us to spot not working, untested code and fix those code.
4. Increase the number of contributors by lowering the entry cost.
5. Last but not least, the problem in the patch on the axes file is not that we are doing pep8 changes, but that the file is insanely big (10kloc) and needs to be refactored. This patch just underlines this.

I can continue the list, but I don't see the point in that. If you feel strongly that we should not make those pep8 changes, I think this discussion should happen on the mailing list, not on github, so that everyone can be aware of it and chime in.

@ivanov
Collaborator

@NelleV Thank you for your contributions (and all the future ones, too :+1: !). The last thing I want to do is discourage anyone from participating. We all volunteer our time and effort and I did not intend to take anything away from the work you've been doing.

I really mean "party" quite literally in "being late to the party" - development in these projects is always a rush of excitement and fun for me, and I hate it when anyone or anything derails that - so I apologize if I caused those kinds of feelings.

I have no arguments against PEP8 compliance, and do feel strongly that mpl should converge toward PEP8. PEP8 is great! (I use kevinw/pyflakes-vim and vim-scripts/pep8.git, btw - go team vim!) When I wrote "this is a pretty big sign that we shouldn't even be doing this in the first place" - the "this" was referring to "this big of a change to the codebase" I was simply trying to convey the sentiment that @efiring also expressed in [mpl-devel] strategy for 1.2.x, master, PEP8 changes:

We have a flood of PEP8 PRs based on master, many of which have been merged, some by myself--so I have no objection to this aspect of the situation, though I would have preferred a slower pace, a garden hose rather than a fire hose.

I added the emphasis. I also wrote

I think style changes are fine as they are incorporated in actual changes to the code, but having purely stylistic changes all through the code base (and in tons of separate commits throughout the codebase) is the wrong way to go.

but here, I was actually trying to express my preference for doing PEP8 changes, and reading back through the mailing list archives, it seems no one else brought up this concern, so I'm fine with this going full steam ahead! And I'm tired too, and what I wrote there doesn't even make sense since it's inconsistent with me being frightened by having to drink from a fire hose - separate commits on separate files (the way you've been doing them) actually is the way to go with making such changes. There'd be no way in hell to review one incredibly long diff that just makes all PEP8 fixes in the whole codebase -- so I'm going to go back and cross out the rest of that sentence in the original.

@WeatherGod
Collaborator
@NelleV
Collaborator

@WeatherGod: I'll proceed in splitting this PR into smaller chunks so that it can be reviewed then.

I'm closing this PR.

@NelleV NelleV closed this
@pelson
Collaborator

I'll proceed in splitting this PR into smaller chunks so that it can be reviewed then.

That would be great, thanks @NelleV! I've just been PEP8-ing a code base for another project and I know how tedious doing this can be - it is very much appreciated!

@ivanov : I can see the problem you are describing on the web interface, and agree that is certainly a downside to doing stylistic changes in one go, but can't figure out how the stylistic changes (which don't break anything) can impact git bisect.

EDIT: I missread your post @ivanov - It doesn't effect git bisect it effects git blame. I've never used git blame... please ignore me! :smile:

@dmcdougall
Collaborator

@pelson I have used git blame. It's actually really useful if you need to follow up on a line change.

@NelleV
Collaborator

@WeatherGod I've finished the pep8 fixes on the axis module. I've got another PR to remove some code, but I think you can start refactoring. I had a look at how to do that, and a small refactoring based on classes seem easy to do. The rest is going to be much harder... (I managed to create a submodule axes, with 2 files, but one of those is still 8kloc long)

@NelleV
Collaborator

@WeatherGod I was wondering whether you started on the refactoring of the axes module: if not, I can work on this.

Cheers,
N

@WeatherGod
Collaborator

Go right ahead. Don't wait for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Nov 5, 2012
  1. @NelleV

    PEP8 fixes on axes.py

    NelleV authored
  2. @NelleV

    PEP8 fixes on axes.py

    NelleV authored
Something went wrong with that request. Please try again.