@madpilot @rene Someone loop python@ in and get them to properly hook up tauthon 2.8 into the framework (I am not knowledgeable so I require support, else I would have done it weeks ago) so we can see which of the ports will work on tauthon, for instance, mailman is also a candidate -- and which handful of requisites may need a Tauthon flavor. This would offer a perspective for those ports where we won't get (compatible) Python 3.x based versions from the upstream, or where upstream made a mess of the Python 3.x enabled versions.

In D28665#645338, @rene wrote:

Python 2.7 (and Tauthon) removal preview, tentatively for June 23. Lots of KDE gone...

We need to install a maintained platform to execute Python 2.7 code on, for instance, Tauthon - this is for mail/mailman (mailman 2.1) which is maintained but in feature freeze. mailman3 is a rewrite-from scratch that works differently and has no migration path.

In the light of findings mentioned in D27954 we might want to add removal of .bak files, but other than that my proposal already looks in-depth at the REINPLACE_ARGS, to complain if something uses a nonstandard -i argument (backup suffix).

REINPLACE_CMD or something similar will be needed for machine edits of ports that were not developed by upstream with BSD portability in mind.
Abandoning REINPLACE_CMD altogether will see workarounds filed, and those will very likely escape the QA we have in place.

Two inline comments, else no objections from me, but no complete review either (I checked those areas I maintain and skimmed the others only cursorily. Nothing striking out as unacceptable though.)