Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Deprecate Axes3D.w_{x,y,z}axis in favor of .{x,y,z}axis. #11387

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

Merged
merged 1 commit into from
Mar 15, 2019

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Jun 6, 2018

PR Summary

See discussion at #11385 (comment) for rationale.

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

return self.yaxis

@property
@cbook.deprecated("3.0", alternative="zaxis")
Copy link
Member

Choose a reason for hiding this comment

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

We should give an explicit removal date. These attributes have been here for 10+ years, and I still see them used in submitted examples and questions. So the usual deprecation cycle may not be long enough for most people.

Copy link
Member

Choose a reason for hiding this comment

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

+1 to take it slow. It's not hurting much. One could go for a pending deprecation warning first, and maybe target removal="4.0".

Copy link
Member

@timhoffm timhoffm left a comment

Choose a reason for hiding this comment

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

There's also still a ax.w_zaxis in the surface_3d_3.py example that should be replaced.

return self.yaxis

@property
@cbook.deprecated("3.0", alternative="zaxis")
Copy link
Member

Choose a reason for hiding this comment

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

+1 to take it slow. It's not hurting much. One could go for a pending deprecation warning first, and maybe target removal="4.0".

@anntzer
Copy link
Contributor Author

anntzer commented Jun 7, 2018

By default, cbook.warn_deprecated("3.0") will emit a warning with a scheduled removal in 3.2. I don't particularly like scheduling removal in 4.0 (that's way too vague), so I completely removed the scheduled deprecation instead. (Is 3.3 enough? 3.4? 3.5? the question is a bit pointless IMO.)
I also don't see the point of PendingDeprecationsWarnings, tbh...
Or feel free to propose a better solution.

@timhoffm
Copy link
Member

timhoffm commented Jun 7, 2018

As I understand it, PendingDeprecationWarnings are helpful for third party packages using matplotlib. If they use ax.w_zaxis and we deprecate it right away, the change will be visible to end users and 3rd party devs at the same time. The end users will see the deprecation messages, but cannot do anything about it because it's not in their code.

On the other hand, a PendingDeprecationWarning is ignored by default. The end user will not see it. But the 3rd party package dev can enable these warnings in his tests. He then can recognize and fix a use of a to-be-deprecated element without the end user seeing a message about this ever.

That said, I seems we are always generating a MatplotlibDeprecationWarning, even when warn_deprecated(..., pending=True) - other than indicated by the docstring. We should actually be issuing a PendingDeprecationWarning in that case.

Note: We do not have a pending deprecation in our current code base.

@anntzer
Copy link
Contributor Author

anntzer commented Mar 14, 2019

Changed the deprecation to a PendingDeprecationWarning with no scheduled removal yet.

@@ -24,16 +24,16 @@ class MatplotlibDeprecationWarning(UserWarning):
def _generate_deprecation_warning(
since, message='', name='', alternative='', pending=False,
obj_type='attribute', addendum='', *, removal=''):

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This patch doesn't change the logic, just clarifies that pending deprecations have no scheduled removal.

@WeatherGod WeatherGod merged commit f2e0479 into matplotlib:master Mar 15, 2019
@anntzer anntzer deleted the worldaxis branch March 15, 2019 14:01
@QuLogic QuLogic added this to the v3.2.0 milestone Aug 31, 2019
@tacaswell tacaswell modified the milestones: v3.2.0, v3.1.0 Sep 1, 2019
@tacaswell
Copy link
Member

I think I see what happened here. This got merged after we branched for 3.1, it did not get backported, to v3.1.x, but when we did the API notes consalidation it was against master branch in #13870 we did pick up that change so we currently have this documented as deprecated at https://matplotlib.org/3.1.0/api/api_changes.html#axes3d but the code is not actually warning.

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.

5 participants