Proposed update to PEP-11 on Unsupporting a platform (less draconian measures)

When a platform loses Tier support status as defined in PEP-11 : Unsupporting platforms, the current text is rather draconian. It claims we must break the build and configure for said platform.

This seems unreasonable. We do not treat non-PEP-11 Tier supported platforms in this manner (many of which are widely used regardless of active support at PEP-11 standards levels such as other BSDs, Solaris, and AIX). So we should not punish a platform and its users when the last remaining individual keeping it in mere Tier 3 decides that isn’t something they can do with anymore.

PR with the proposed wording edits to have us just ask build/configure to issue a Warning on no longer tier supported platforms: PEP-11: Make unsupporting a platform less draconian by gpshead · Pull Request #3633 · python/peps · GitHub

This came up as a steering council discussion topic recently as wasm32-unknown-emscripten was bumped out of Tier 3 into Unsupported land.


Maybe there is a middle ground here where the build fails by default but can be allowed more easily than by patching the build system, by passing an option like --allow-unsupported-platform?

My uninformed opinion worth μ¤ 0.02 is that a lot of people never read warnings, especially on obscure platforms that are just tested by a CI, so failing by default is a good way to avoid the classic “But it was working!! Why break it!!??” “Well, we announced the change long ago.” “But I had no way to know! Do you really expect me to read the changelogs of my 500 dependencies!!?” (as famously happened in cryptography).


I’d like to cast a vote for including a pointer to how to override the
refuse-to-build failure in the warning. An administratively “off” option
with no clear path to turning it “on” is very frustrating.

1 Like

This is why the proposal PR changes it to not require a refuse-to-build failure. We don’t need more flags.


I personally support this as the PEP 11 maintainer.

I’m all for this change; it’s much better than the current version.

But there’s one thing I don’t fully understand: Who is this error/warning for? Whose behaviour should it change, and how?

1 Like

I believe the original motivation for the error is to notify users who are not keeping up with CPython development and What’s New to know a change to the platform they care about has occurred. I think it was also meant to see if more people would come forward to help support a platform.

Like I wonder how many people know what platforms we do support even if we do happen to compile somewhere? Do they assume it’s officially supported?

I agree this means unnecessarily hostile. Did we actually do that?

And does it matter to them? We handle/close issues based on whether a volunteer wants to work on them. IMO, PEP-11 is mostly a summary of what we want to work on, written for Python devs/triagers – so that you know who to bug for a particular platform, or whether you should “revert first and fix later” when something goes red.

For users, there’s very little actionable information in PEP-11.

Trouble is, they did come forward, and asked what they should do to help support a platform. We have no good answer. And that’s fine, really – it’s OK to do what seems best, and only standardize after it happens a few times. But we should probably acknowledge that Emscripten is in this experimental phase, and do what’s best for it rather than take PEP-11 too literally (and amend it whenever a detail needs changing).

(Sorry for hijacking the thread to talk about the bigger picture. The proposed change is a definite improvement.)


Also, given the widespread availability of binary packages of the CPython interpreter, anyone compiling CPython themselves is pretty much in “expert” territory already. You may display a warning if someone compiles on a non-PEP 11-anointed platform, but I don’t think there’s any value in being stricter.


Here’s my effort to improve things:

I’m doing things that (IMO) don’t need explicit SC approval. Feel free to follow along, and stop me you disagree with anything. A proposal will come later, if necessary.
As for Docs, which now have a fancy Editorial Board, my hidden agenda for this ”skunkworks” project is to collect interested people, and keep them interested :‍)


Whoever happens to see it hidden in the morass of build system output. So realistically only someone working to interactively build Python on a platform frequently enough.

I consider it basically an “FYI”. Kind of like we have with the “you know there’s an --enable-optimizations flag that you didn’t use?” message…

I don’t think existing warnings are necessarily well placed, but moving things around so they’re seen perhaps at the end of configure or end of a build isn’t specified (and isn’t going to be specified, lets not overthink it) and is a normal tweak anyone could make via a PR.

No strong objections noticed here and general agreement that we’re don’t proactively break builds on a status change, so I’ve set the PEP-11 update PR to automerge. Thanks everyone!