GeezerVison

🤖 New build scheduled with the buildbot fleet by @encukou for commit 2772bc6 🤖

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

Buildbots are green except:

• WASI & Windows-bigmem builders fail to build 3.9 at all
• macOS fails on unrelated issue (idle)

@ambv Do you want PEP-706 backported to 3.9?

@encukou if so, 3.8 is also still supported for security fixes. I'd lean +0 because it would:

• 👍🏻 making the automated security checkers happy with those versions of Python; but
• 👎🏻 most users of Python 3.9 won't be building and installing 3.9.17 anyway; and
• 👎🏻 user code would have to employ a check for whether the filter functionality is available, and since this check will likely fail on 3.9 -- implement a workaround themselves anyway.

implement a workaround themselves anyway.

The workaround is quite involved in this case, so one of the suggestions is:

if hasattr(tarfile, 'data_filter'):
    my_tarfile.extractall(filter='data')
else:
    # remove this when no longer needed
    warn_the_user('Extracting may be unsafe; consider updating Python')
    my_tarfile.extractall()

See the PEP's section on backporting: https://peps.python.org/pep-0706/#backporting-forward-compatibility

most users of Python 3.9 won't be building and installing 3.9.17 anyway

FWIW, in RHEL we'll probably need to backport regardless of your decision (and probably go with a more aggressive variant, to boot).
Having it upstream could make life easier for other redistributors.

And yes, if it goes in, 3.8 and 3.7 is next.
Again FWIW: Red Hat is likely to put it in 3.6 as well.

@encukou if you're going to do it for Red Hat anyway, I will happily take it for 3.9 and 3.8. The window for 3.7 support closes in June and I'm sure @ned-deily would accept the filter for the last release of that, too.