With a comment from a Numpy/SciPy maintainer in support of the PR, I’ll merge it.
Thanks everyone for sharing your concerns, and sorry that I can’t make everyone happy.
There’s still time to revert the multiple-args, or the whole un-deprecation – convince me, or bring it to the SC.
My opinions (weakly held):
Is it worth having two very similar APIs which accomplish the same thing?
I do think it’s good to have this kind of façade on top of the Traversable API, like we have import on top of finders and loaders, or len() to call .__len__(). One for everyday use, one to implement the internals or for special uses.
Would it be helpful to have to explain to users that they can’t use the old API in older Python versions (or at all) if they’re recursing into a package?
That’s quite normal for a new feature.
But if we’re talking about old Python versions, note that the still-supported Python 3.8, doesn’t have importlib.resources.files. I assume that’s why some projects are delaying to switch (and welcoming the un-deprecation).
I assume you knew that given the next question:
can the deprecation period simply not be extended until the oldest supported Python version has the new API, if you feel that the removal is premature?
That’s definitely a possibility! But why not make the deprecation period even longer than that? After all, some portion of the community still targets LTS Linux distros, with longer support than you get for python.org builds.
(Funnily enough, a question like this started me on the way to write this PR.)