-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
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
Conversation
lib/mpl_toolkits/mplot3d/axes3d.py
Outdated
return self.yaxis | ||
|
||
@property | ||
@cbook.deprecated("3.0", alternative="zaxis") |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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".
There was a problem hiding this 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.
lib/mpl_toolkits/mplot3d/axes3d.py
Outdated
return self.yaxis | ||
|
||
@property | ||
@cbook.deprecated("3.0", alternative="zaxis") |
There was a problem hiding this comment.
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".
By default, |
As I understand it, PendingDeprecationWarnings are helpful for third party packages using matplotlib. If they use 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 Note: We do not have a pending deprecation in our current code base. |
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=''): | |||
|
There was a problem hiding this comment.
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.
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. |
PR Summary
See discussion at #11385 (comment) for rationale.
PR Checklist