René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"MatplotlibDeprecationWarning removal hard-breaks seaborn in 3.6rc1","articleBody":"This removal hard breaks a seaborn function.\r\n\r\n\u003e Also it's rather unlikely for end users to import MatplotlibDeprecationWarning.\r\n\r\nCurious what the basis for this claim was? https://github.com/search?q=%22from+matplotlib.cbook+import+MatplotlibDeprecationWarning%22\u0026type=Code shows 2k+ direct imports of this class, and searching for alternate usage patterns turns up others as well.\r\n\r\n\u003e I don't think we have or easily could have added a warning on importing the class\r\n\r\nI agree that this would have been hard! But IMO that puts the burden on matplotlib to deprecate with a bit more care (e.g., proactively searching for usage in downstream libraries, etc.). You are right that this was \"properly documented\", but it is mentioned in the middle of a very long list of API changes (there are \u003e4000 words on https://matplotlib.org/stable/api/prev_api_changes/api_changes_3.4.0.html). Downstream libraries have the reasonable expectation that they can rely on unit test coverage to surface deprecation warnings, since matplotlib is usually good about that sort of thing.\r\n\r\nIn the future, please boost the signal of any silent deprecations.\r\n\r\n_Originally posted by @mwaskom in https://github.com/matplotlib/matplotlib/issues/22514#issuecomment-1223907658_","author":{"url":"https://github.com/tacaswell","@type":"Person","name":"tacaswell"},"datePublished":"2022-08-23T14:25:16.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":5},"url":"https://github.com/23716/matplotlib/issues/23716"}