On Fri, Mar 25, 2022 at 8:32 PM Brett Cannon <brett@python.org> wrote:
>
> Thanks to Petr, and Victor, the platforms that are still looking for a total of two maintainers over at https://github.com/python/peps/pull/2442/files are:
>
> arch64-apple-darwin clang
> aarch64-linux-gnu glibc, clang (Victor is already listed)
> aarch64-windows-msvc
> powerpcle-linux-gnu glibc, clang
> s390x-linux-gnu glibc, gcc
> s390x-linux-gnu glibc, clang

FWIW, I'm not listing myself for s390x. While fixing Python for
mainframes is part of my job at Red Hat, I don't have immediate access
to such machines and can't promise timely fixes.
When I (or Victor or someone else) comes up with a fix, we'll of
course want to contribute it to CPython, but I think Tier 3 is fine
for that. Usually these fixes *make Python conform better to the C
standard*, e.g. avoiding endianness/bit-pattern assumptions. I assume
such fixes should be welcome regardless of platform. But, if we don't
have a big-endian arch in the 2 tiers, endian-specific code does
“cause a maintenance burden or obstruct general improvements”. Same
for e.g. code that relies on “common” implementation details in malloc
or something like that.

Should the PEP explicitly say that fixing deviations from standard C
is welcome, even if they don't manifest on the tiered arches?