Quick question but how do you manage the whatsnews sections when a feature is being removed? I cannot really change it to :func:`!pkgutil.find_loader` since these are available in previous versions.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Yes, that's what I was actually asking. Should I just suppress every possible links in the others 3.x.rst files even though they exist? (if so, I can do it but I wanted to be sure that all references should be suppressed even for old versions for which the reference would exist).

Again, older versions won't be affected, because they live in their own branches. And we won't backport this change.

Oh yes, it was dumb of me. I incorrectly assumed that the 3.12 page was for the corresponding branch (seems I'm still not entirely awake). Anyway, I have made the requested changes; please review again.

Thanks for making the requested changes!

@sobolevn: please review the changes made to this pull request.

I'm not an expert in this since this predates the time when I started coding in Python (technically speaking, I've coded in 2.7 but never in 3.0 -- 3.5).

AFAIK, the pkgutil.extend_path function is not marked as deprecated even though namespace packages should not be declared through it anymore. However, if needs arise, I'd recommend removing extend_path in one go rather than removing a single portion of the code.

The main reason is: extend_path should not really be used since it's for declaring legacy namespace packages; but if someone really wants to use it, then it should do whatever it was meant to do.

In particular, having removed find_loader from pkgutil does not mean that a custom Finder object should not be used for extend_path.

This has a conflict after the #122085 re-org.

Oh, I forgot about this one :') I'll fix the conflicts err... I don't know when (I'm a bit busy writing something currently and don't know if I'll have tomorrow)

Thanks, absolutely no rush with this :)

#123036
Need change

@picnixz are you waiting on anything for this? You haven't triggered a request for a re-review.

Oh I forgot about it. This one is a low-priority task (which is why I didn't re-request a review) and we were waiting for more experts feedback (such as yours I think?) so we can address this issue when people have the time!

(I'll be barely present for the rest of the week)

Where are we up to here?

Our friends at Fedora, who do a huge amount of valuable early testing and fixing of Python packages, are asking about pending deprecations for 3.14:

https://discuss.python.org/t/if-you-plan-to-remove-deprecated-apis-from-python-3-14-please-do-it-now/67955

I always forget about this PR :D We actually waited for an expert on pkgutil to confirm that the removal is ok. Apart from that, I don't think I wanted to do more. I'll ask a round of re-review.

We actually waited for an expert on pkgutil to confirm that the removal is ok

There is no pkgutil expert, hence the deprecation (that and it not plugging into importlib cleanly). 😉

Let's merge!