From my announcement on python-devel and packaging lists:

I have just updated python-rpm-generators to python-rpm-generators-11-1.fc33 in Rawhide. It uses some fresh stuff from RPM 4.16 and will not be backported to older releases.

The python(abi) requirement is now added from a RPM Lua macro, instead of by executing a Shell script. This is a bit faster especially for packages with a lot of files. For 10 000 files in one package, the speedup is roughly from ~80 to ~2 seconds (time of the entire package build incl. creating the files from a Python script). That is a lot, but most of the real packages have much less files, so I am afraid you won't feel it.

More importantly, %python_provide is not needed for package names.
Until now, we needed to this:

%package -n python3-foo
...
%{?python_provide:%python_provide python3-foo}

This adds automatic provides "python-foo" (and since recently, also "python38-foo" for forwards/backwards compatibility with EL). This now happens automagically. Any package called "python3-..." will have those provides added implicitly by the Python generators when they are in the buildroot (python3-devel brings those in, so for Python packages this means always).

This automation was possible due to the speedup mentioned above, doing it the pre-RPM.16 way would be very slow, because the generator is called for every packaged file (which is still the case now, but it can now be a Lua macro). The ~2 seconds from above include this new feature.

There are 2 cases where manual %python_provide calls are still needed:

1. Metapackages without files

No files => no dependency generator. (I recommend to %ghost the dist-info/egg-info directory in such packages to workaround this -- we plan to add more good stuff regarding Python [extras] that will require this anyway.)

1. Virtual provides

The dependency generator can see the (sub)package's name, but not any other virtual provides. When you do:

%package -n python3-%{pypi_name}
Provides: python3-%{legacy_name} = %{version}-%{release}

You are still supposed to add:

%{?python_provide:%python_provide python3-%{legacy_name}}

(Also note that %python_provide adds obsoletes for older python-foo versions, that was useful when we renamed everything from python-foo to python2-foo and when we changed the "default" from python2- to python3-. We are keeping the Obsoletes in the macro (for now), but I have decided to not automatically generate the Obsoletes based on the package name. A) I don't consider them really needed in Fedora 33 any more and B) an idea of implicit obsoletes doesn't sound very intriguing to me. This is a decision that may be revisited later if it's bringing unforeseen trouble.)

You don't need to to actively remove the macro from your spec files, it does no harm. If you prefer to maintain a single spec, keep it there until Fedora 32 goes EOL (and EPEL 8 if that's your target). The guidelines always recommended using it the safe way (%{?python_provide:...}), so even if it ceases to exist in the future, it can remain in specs. There is no plan to remove it in any near or distant future, as it is still needed for the virtual provides. The generators also use it internally (for DRY and consistent results).

This is my note to amend the guidelines accordingly.