-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Deprecate unused testing cleanup mechanisms #17042
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
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.
Please use the deprecation decorators.
@@ -35,58 +35,6 @@ def _cleanup_cm(): | |||
plt.close("all") | |||
|
|||
|
|||
class CleanupTestCase(unittest.TestCase): |
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 isn't a deprecation, you have just removed these.
What is the motivation for deprecating these? Just general cleanup?
I take #14329 (comment) to mean that @anntzer would explicitly like to keep these methods. |
I am currently learning deprecations here. Earlier, in deprecations
at other orgs, we remove that code OR use another method/class that is more
robust instead of the current one. So, there is tech stack difference too.
So, I am currently learning about decorators and wrappings. :-)
I will deprecate them by decorators.
…On Tue, Apr 7, 2020 at 9:34 PM Jody Klymak ***@***.***> wrote:
I take #14329 (comment)
<#14329 (comment)>
to mean that @Annzter <https://github.com/Annzter> would explicitly like
to keep these methods.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#17042 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFAAEQ3GOHLHXBVCLB26KZTRLNFHHANCNFSM4MCDU4LQ>
.
|
I think these can/should stay for now. @SidharthBansal Matplotlib is a very widely used library, and effectively anything that we expose is likely used by tons of people regardless of whether we intended it for external use or not. Thereforce we try not to remove stuff unless there's a clear reason to ("clear" being something that you can only evaluate with some experience...) and even then, we need a deprecation period where the thing stays but third-party users who rely on it get a warning that the API is going away. In this specific case, I think this API has a legitimate use case and is self-contained enough that it does not cause undue maintenance burden by staying. Obviously @timhoffm had a different opinion in #17042 and may therefore want to chime in. |
we need a deprecation period where the thing stays but third-party users
who rely on it get a warning that the API is going away.
That is a new thing I learnt today. Thanks for thorough explanation. So,
shall I deprecate it OR we are aiming at closing the PR? If we are willing
to close the PR, my humble suggestion will be to attach `wont-fix` type
label(whatsoever used here) at respective issue so that no one else will
attempt to submit a pr for it until we necessarily need it or simply close
the issue.
Thanks for helping me. You all are very helpful :-)
…On Tue, Apr 7, 2020 at 10:20 PM Antony Lee ***@***.***> wrote:
I think these can/should stay for now.
@SidharthBansal <https://github.com/SidharthBansal> Matplotlib is a very
widely used library, and effectively anything that we expose is likely used
by tons of people regardless of whether we intended it for external use or
not. Thereforce we try not to remove stuff unless there's a clear reason to
("clear" being something that you can only evaluate with some
experience...) and even then, we need a deprecation period where the thing
stays but third-party users who rely on it get a warning that the API is
going away.
In this specific case, I think this API has a legitimate use case and is
self-contained enough that it does not cause undue maintenance burden by
staying.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17042 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFAAEQ6OVNRN6RU43HG3XATRLNKU5ANCNFSM4MCDU4LQ>
.
|
My opinion is to close as wontfix, but again let's give @timhoffm time to give his opinion as well. Or sometimes issues just need more discussion :) |
I think we can proactively close this. If @timhoffm wants more discussion, he can re-open. |
Agreed!
…On Tue, Apr 7, 2020 at 10:53 PM Antony Lee ***@***.***> wrote:
My opinion is to close as wontfix, but again let's give @timhoffm
<https://github.com/timhoffm> time to give his opinion as well. Or
sometimes issues just need more discussion :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17042 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFAAEQ6BUUPATCSD5PQHYBTRLNOSPANCNFSM4MCDU4LQ>
.
|
@anntzer I'm fine with keeping if you think it's worth it. |
PR Summary
The class matplotlib.testing.decorators.CleanupTestCase and the decorator matplotlib.testing.decorators.cleanup are not used in the code base. We have an automatic cleanup via an auto-used fixture instead. This PR removes them.
Fixes #14329
PR Checklist