PEP8 on artist #1153
PEP8 on artist #1153
Conversation
| @@ -753,15 +753,17 @@ def findobj(self, match=None, include_self=True): | |||
| .. plot:: mpl_examples/pylab_examples/findobj_demo.py | |||
| """ | |||
|
|
|||
| if match is None: # always return True | |||
| def matchfunc(x): return True | |||
| if match is None: # always return True | |||
There was a problem hiding this comment.
The comment is in the wrong place (not your fault) and is therefore misleading. Should be on the function itself.
There was a problem hiding this comment.
I actually think there is a problem with this method. Not far after this code, there an::
elif callable(match):
matchfunc = func
func is not defined anywhere in this method. I'm pretty sure it is meant to be matchfunc = match.
|
Looks good. For me this is a massive improvement, despite the fact that I don't really like wrapping list comprehensions. Will merge this in 48 hours. |
|
Please don't merge this until the branch has been created. We're in a feature freeze. |
This doesn't add any features. Merging this after taking the 1.2.x branch will cause horrible conflicts (either for the merger of this, or for whoever took branches before this got merged). We have restrained from implementing PEP8 changes during the v1.1.x lifecycle for precisely these reasons and IMHO now is the perfect time to do this kind of leg work (for which we are all grateful @NelleV ). I will not merge while @mdboom holds the objection, but I cannot see a better time to merge it than right before a new release branch is taken. |
|
My concern is about keeping the existing PRs for 1.2.x to apply cleanly without requiring a potentially time consuming rebase. It's less of a concern to have difficult to merge things later. |
|
I can keep the PR up to date with merges in master until you think it is OK to be merged if you don't mind me rebasing the code. |
|
Let's do this as a compromise -- I'm going to try to clean out as many other PRs for 1.2.x today as I can, and then following that we can put some cleanup things (such as this) prior to the RC. |
|
I'm not familiar with matplotlib's development process. I'm cleaning up some other files. Should I update this PR with the other PEP8 compliant file or keep that "in stock" until you guys are ready to merge the PEP8 patches ? |
|
Feel free to add them to this PR or a new PR. (Doesn't really matter). The only thing we're holding off on a bit is the merging. Thanks for this work, by the way. It's long overdue. |
| self._isinit = False | ||
|
|
||
|
|
||
| # FIXME FIXME FIXME bytes is a *keyword* in python |
There was a problem hiding this comment.
I'm not sure if we should deal with this small issue here: bytes is a keyword in python. Changing that would, I guess, break backwards compatibility.
There was a problem hiding this comment.
That should be a separate PR, which can involve introducing a new keyword ("asbytes"?) and deprecating the old one with a warning, while changing all uses within mpl to the new version. Not urgent.
(bytes is not a python keyword but a relatively recent builtin type.)
|
@NelleV: I think it would be better to remove those last 2 commits. In general, more smaller PRs are better than fewer larger ones. I would be happy to review each file separately (given that these are considerable in size, if not in code changes). Thanks. |
|
OK, I'll create severals PRs. If that's OK, I'd like to close this one, and create a new one in a branch. I didn't expect the merge to be delayed so I worked in master. It's now being a burden for me. |
|
Sure. You can push a renamed branch to your fork without a problem (keeping the same commit sha): might just do the trick. |
|
For the other two, you can just take new branches and cherry pick the respective commits. |
This is a simple PEP8 PR on the submodule artist I did while reading the code.