
On Mon, Mar 28, 2022 at 7:09 AM Petr Viktorin <encukou@gmail.com> wrote:
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?
I don't think so. That's simply a compatibility thing that we have always done regardless of platforms. It's basic code health to adhere to the C standard for us.