deprecation of validCap, validJoin makes pydoc spam out many, many warnings #19080

Activity

1. anntzer

   added

   Documentation

   on Dec 7, 2020
2. brunobeltran commented on Dec 8, 2020

   

   brunobeltran

   on Dec 8, 2020

   Contributor

   More actions

   Interesting. I don't see a way around the fact that if we're going to emit a UserWarning on class attribute access, then modules that systematically import/inspect class attributes are going to trigger a computer-generated amount of copies of this warning.

   Even when building our docs, in order to prevent this, there is a special filter ignoring any MatplotlibDeprecationWarnings coming from sphinx.util.inspect directly.

   That said, to me this is clearly a case of deprecation warnings causing more annoyance than they do good, since people inspecting the class using standard tools should not be spammed by us.

   This issue may be the first concrete argument for why we should make MatplotlibDeprecationWarning an actual DeprecationWarning instead of a UserWarning. The filter that was added in Python ~3.2 (and amended most recently in https://www.python.org/dev/peps/pep-0565/, I think?) prevents this issue if MatplotlibDeprecationWarning is a subclass of DeprecationWarning, as the point of those changes was exactly to hide deprecation warnings from "end users" like someone running pydoc.
3. brunobeltran commented on Dec 8, 2020

   

   brunobeltran

   on Dec 8, 2020

   Contributor

   More actions

   I see three reasonable paths for resolution:

   1. Undeprecate validJoin/validCap, assuming that the annoyance of having any inspection of the many Patch subclasses for now until 3.6(?) emit unnecessary warnings outweighs the extremely marginal benefit of getting rid of the small code cruft.
   2. Document exactly who we intend to see our DeprecationWarnings in the first place, and consider whether or not moving towards MatplotlibDeprecationWarning subclassing DeprecationWarning (which effectively would just change what default warning filters are applied to it, since DeprecationWarning is a UserWarning) might actually be a good idea.
   3. Replicate the relevant warnings filter that we would be getting from subclassing deprecation warning, but make it specific to matplotlib and to the class attribute access deprecation machinery. While I know the opinion of @tacaswell is that a library shouldn't modify "global state" like the warnings filter list, I think the fact of the matter is that is the only tool that Python provides library writers for dealing with exactly these issues, so it would make sense to use it (like other packages already do).
4. QuLogic commented on Dec 8, 2020

   

   QuLogic

   on Dec 8, 2020

   Member

   More actions

   Avoiding the larger point, can we deprecate on at least write only?
5. timhoffm commented on Dec 8, 2020

   

   timhoffm

   on Dec 8, 2020

   Member

   More actions

   Technically, it is sufficient to document the deprecation in API changes. We don't have to issue runtime warnings. Sure, a runtime warning is more discoverable, but if it's doing more harm than good we can go without it.
6. brunobeltran commented on Dec 8, 2020

   

   brunobeltran

   on Dec 8, 2020

   Last edited by brunobeltran

   Contributor

   More actions

   Avoiding the larger point, can we deprecate on at least write only?

   I can definitely push this, although I'm not sure it's worth the effort, since in this particular case I'm....frankly not sure who we're targeting with that message.

   Technically, it is sufficient to document the deprecation in API changes. We don't have to issue runtime warnings. Sure, a runtime warning is more discoverable, but if it's doing more harm than good we can go without it.

   I'll bring this up as a quick point in today's call if it happens, that might be the way to go.
7. jklymak commented on Dec 8, 2020

   

   jklymak

   on Dec 8, 2020

   Member

   More actions

   Cross ref #18817
8. jklymak commented on Dec 8, 2020

   

   jklymak

   on Dec 8, 2020

   Member

   More actions

   • suggested during the call that maybe instead of deprecating, Line2D.valid_JoinStyle could just call through to JoinStyle.valid_strings or whatever top-level class holds that info....
9. github-actions commented on Sep 18, 2023

   

   github-actionsBot

   on Sep 18, 2023

   More actions

   This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
10. github-actions

    added

    status: inactiveMarked by the “Stale” Github ActionMarked by the “Stale” Github Action

    on Sep 18, 2023
11. QuLogic commented on Sep 18, 2023

    

    QuLogic

    on Sep 18, 2023

    Member

    More actions

    These deprecations were removed in 3.6, so I guess there's nothing to worry about here any more.
12. QuLogic

    closed this as completedon Sep 18, 2023
13. QuLogic

    removed

    status: inactiveMarked by the “Stale” Github ActionMarked by the “Stale” Github Action

    on Sep 18, 2023
14. QuLogic

    added this to the v3.6.0 milestone on Sep 18, 2023