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.

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).

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

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.

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.

Cross ref #18817

• 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....

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!

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