Questions from Deprecation of importlib.resources legacy API

[jaraco]

In this thread, I provide background on the motivation and considerations of migrating the importlib.resources API from one form to another, summarized thus:

• In Python 3.7, importlib.resources introduced the (now legacy) API and provided a backport in importlib_resources.
• In Python 3.11 and importlib_resources 5.4, the legacy functionality is deprecated and slated for removal in Python 3.13 and importlib_resources 6.0 (or later).
• The replacement functionality is available on Python 3.9 and importlib_resources 1.3 (supporting Python 2.7 and later).
• As a result, the deprecation meets a more conservative standard than required by the policy. In particular, it meets this higher standard:

The backward-incompatible change should not be made until the replacement is available in all supported Python versions, and the DeprecationWarning should not be introduced until as late as possible (two minor releases prior to the removal).

Despite these considerations, there is a good deal of consternation and even hostility from the community about this change, with requests to "move slower" or "stop changing things".

The SC has already weighed in implying that it's sufficient for changes to meet the policy.

Questions:

• Should a more conservative policy such as quoted above be applied to all backward-incompatible changes in the standard library? If not, under what circumstances should a more conservative approach apply?
• Even following that more conservative policy, the community is dissatisfied with the pace of change (characterized as churn). Should the policy be made even more conservative to slow the pace of change (e.g. require 3+ years of replacement availability before deprecating, require replacement to be in all supported versions before deprecating)?
• Does having a backport affect how aggressive or conservative a stdlib package should be about incompatible changes?
• What other factors would you advise importlib.resources to consider around this issue that aren't spelled out in a policy?

[brettcannon]

I've added this to our rolling agenda.

[brettcannon]

We discussed this and the deprecation policy is being followed in this case and we think the policy is reasonable in lieu of the external package. But if people want to discuss changing the overall policy that can/should occur on python-dev.

[jaraco]

Thanks for your consideration.