Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix rc grid parameter inconsistency #2110

Merged
merged 2 commits into from Aug 18, 2013
Merged

Conversation

Carreau
Copy link
Contributor

@Carreau Carreau commented Jun 2, 2013

This is a first attempt at fixing #2109.

It introduces a condition in /lib/matplotlib/axis.py:Ticks that set gridOn to the rcparam only if Tick is major, and add an rcparam axes.grid.which.

I have a few question that I'll add directly on the relevant line in the File Changed tab.

elif (not major) and (rcParams['axes.grid.which'] in ('both','minor')):
gridOn = rcParams['axes.grid']
else :
gridOn = False
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feel strange to read rcParams here in Ticks if it is called axes, and is already used in axes.py . Moreover, the value of gridOn seem to be passed around here and commenting all this block does indead keep the wanted behavior. I propose to change those rcparams to <x|y>tick.<major|minor>.grid = Bool to be consistent with the all the other parameters.... unless I'm missing something.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that it would be nice to rename the rcparams, but for backward compatibility I'm not sure we can.

@Carreau
Copy link
Contributor Author

Carreau commented Jul 6, 2013

I also added test, not sure if they are correctly written though.

@Carreau
Copy link
Contributor Author

Carreau commented Jul 6, 2013

I'll still be happy to get comment on the previous question,

It feel strange to read rcParams here in Ticks if it is called axes, and is already used in axes.py . Moreover, the value of gridOn seem to be passed around here and commenting all this block does indead keep the wanted behavior. I propose to change those rcparams to <x|y>tick.<major|minor>.grid = Bool to be consistent with the all the other parameters.... unless I'm missing something.

I can also rebase to merge commit together, or shuffle them around to have test-commit before the rest.

You might want me to add a line in the change log for the new rc-param ?

@@ -578,6 +580,10 @@ def __call__(self, s):
'axes.titlesize': ['large', validate_fontsize], # fontsize of the
# axes title
'axes.grid': [False, validate_bool], # display grid or not
'axes.grid.which': ['major', validate_axis_locator],# set wether the gid are by
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We follow pep8 convention: please add two spaces before the comment.

@NelleV
Copy link
Member

NelleV commented Jul 18, 2013

This looks good to me. 👍 for merge

@mdboom
Copy link
Member

mdboom commented Jul 18, 2013

@Carreau: Would you mind rebasing this so we can hit the big green merge button?

@Carreau
Copy link
Contributor Author

Carreau commented Jul 18, 2013

Yes, I will, I saw that it was conflicting. IPython 1.0.alpha first :-)

@Carreau
Copy link
Contributor Author

Carreau commented Aug 6, 2013

Sorry for the time to rebase. Done now. I can't seem to install this dev version of matplotlib on the current machine I am on, so can't run tests, but will try to do tomorrow.

@@ -1664,6 +1664,28 @@ def make_patch_spines_invisible(ax):
host.tick_params(axis='x', **tkw)


def test_rcparam_grid_minor():
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a @cleanup decorator to this function, please?

@Carreau
Copy link
Contributor Author

Carreau commented Aug 18, 2013

Sure, @cleanup decorator added.

dmcdougall added a commit that referenced this pull request Aug 18, 2013
Fix rc grid parameter inconsistency
@dmcdougall dmcdougall merged commit 79bd660 into matplotlib:master Aug 18, 2013
@burnpanck
Copy link

Hm. I wrote a small wrapper around rcParam allowing me to access the params using attribute syntax. Now I have a problem: Should rc.axes.grid return a the value of rcParam['axes.grid'], or should it return a proxy object containing a proxy property for rcParam['axes.grid.which']? In short: This is somewhat breaking intuition, in that the keys of rcParam are not following the rules of a python nested object anymore. Maybe we should consider changing axes.grid to axes.grid.on or something?

@tacaswell
Copy link
Member

@burnpanck You should follow the discussion of moving Artists to a managed attribute scheme (ex traitlets) which may come with such tools built in.

@Carreau
Copy link
Contributor Author

Carreau commented Jun 26, 2015

You should follow the discussion of moving Artists to a managed attribute scheme (ex traitlets) which may come with such tools built in.

Is that on the ML or on one of the issues ( my github issue foo only showed 2 issues not really active) ?

@tacaswell
Copy link
Member

Mostly on the mailing list, @ellisonbg is involved.

@Carreau
Copy link
Contributor Author

Carreau commented Jun 26, 2015

Ok, I think I found it, its the one about SciPy Sprint. Brian is not alway reliable to let the rest of the team know about things like that. I think he is often using the Royal "We" (that part of your charm @ellisonbg). I was not on the dev ML, so I cannot "respond" to the thread, but once I can, I'll share a link to my previous work on that.

@tacaswell
Copy link
Member

I have linked to your previous work a couple of times already.

On Fri, Jun 26, 2015 at 10:45 AM Matthias Bussonnier <
notifications@github.com> wrote:

Ok, I think I found it, its the one about SciPy Sprint. Brian is not alway
reliable to let the rest of the team know about things like that. I think
he is often using the Royal "We" (that part of your charm @ellisonbg
https://github.com/ellisonbg). I was not on the dev ML, so I cannot
"respond" to the thread, but once I can, I'll share a link
http://carreau.github.io/posts/09-Matplotlib-And-IPython-Config.html to
my previous work on that.


Reply to this email directly or view it on GitHub
#2110 (comment)
.

@Carreau
Copy link
Contributor Author

Carreau commented Jun 26, 2015

Ok. I'll try to attend the BoF too, if no conflicts.

@burnpanck
Copy link

You should follow the discussion of moving Artists to a managed attribute scheme (ex traitlets) which may come with such tools built in.

Traitlets based attributes, that's great! I'm not really actively monitoring matplotlib's development (except for reading the release notes, whenever there are), just wanted to point out that this parameter naming could conflict with exactly such concepts. Anyhow, I'm looking forward to this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants