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

Fixed Issue 4346 #6079

Merged
merged 3 commits into from Mar 4, 2016
Merged

Fixed Issue 4346 #6079

merged 3 commits into from Mar 4, 2016

Conversation

paulkirow
Copy link
Contributor

This is a fix for issue #4346

The problem was that when handling parameters labelsize and labelcolor, _apply_params was calling setattr on _size and _color instead of _labelsize and _labelcolor. This is all fine and dandy until something is used that calls _apply_params because _apply_params calls apply_tickdir which will change the padding.

When _size changes, its value gets added to the tick padding thus causing the issue seen in #4346. This also explains why the issue only became apparent when setting major (or both) ticks, it is because minor ticks don't have _size added to their padding values.

_apply_params was calling setattr on _size and _color instead of _labelsize and _labelcolor
@tacaswell
Copy link
Member

Can you also add a test? I would suggest a non-image test where you exercise this and assert that the tick size / color does not change due to it. Ideally the tests should only use public methods.

Also 👍 on tracking this one down, this looks subtle as all get out.

@tacaswell tacaswell added this to the 1.5.2 (Critical bug fix release) milestone Mar 1, 2016
@paulkirow
Copy link
Contributor Author

I will work on this

test will make two calls two set_tick_params.  After the fix the second call should not change any of the ticks color or size values.
The second call to set_tick_params would mess the padding up only after the first call was causing size and color to be set incorrectly.  Thus the test is changed to ensure the root cause is fixed and not the propagation of it
@paulkirow
Copy link
Contributor Author

Hopefully this is sufficient.

axis_1.yaxis.set_tick_params(labelsize=30, labelcolor='red', direction='out')

# Expected values after setting the ticks
assert axis_1.yaxis.majorTicks[0]._size == 4.0
Copy link
Member

Choose a reason for hiding this comment

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

Is there any reliably way to test this using public API?

Copy link
Member

Choose a reason for hiding this comment

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

The reason for asking that is that, long term, we reserve the right to change the private API with no warning or deprecation cycle. Tests that only use public API give confidence that we have done that right but that is eroded if we have to touch the tests as part of the refactor as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That makes sense, I didn't consider the public API. I will look into this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can't seem to find a way to get either of labelsize, labelcolor, size, or color out of the public API. There is a get_markersize in the docs that would return _size, however I don't see it in the code. Should I implement this?

Copy link
Member

Choose a reason for hiding this comment

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

If there is not a good public API, then this is fine. Creating new API for the purpose of testing it is not a good idea!

tacaswell added a commit that referenced this pull request Mar 4, 2016
@tacaswell tacaswell merged commit a44571a into matplotlib:master Mar 4, 2016
tacaswell added a commit that referenced this pull request Mar 4, 2016
@tacaswell
Copy link
Member

backported to 1.5.x as b4c3091

@tacaswell
Copy link
Member

Thanks! And congratulations in what I think is your first mpl contribution 👏

In the future, it is best to make PRs off of a feature branch, not your master branch.

@paulkirow
Copy link
Contributor Author

Will do, and thanks!

tacaswell added a commit to tacaswell/matplotlib that referenced this pull request May 22, 2016
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

3 participants