Repository navigation
Clarifying PEP 11 around dropping support #226
Description
https://discuss.python.org/t/im-stepping-down-as-sponsor-of-emscripten/41064/6 has Pyodide asking how to interpret https://peps.python.org/pep-0011/#unsupporting-platforms and the fact it calls for building to fail to "potential users of the platform a chance to step forward and offer maintenance" while we have no concept of community support w/o a sponsor.
A couple of options that I can think of:
- Take out the line about giving the community a chance to find support
- Change it to say it's a chance to find a core dev sponsor
- We don't require a build error, but we do require a notice in What's New
Activity
gvanrossum commentedon Jan 5, 2024
I personally don't think we need to force a build error. Sure, it's likely in many cases that unsupported platforms will start developing build errors, and that's fine -- but at the same time there's a difference between "not supported" and "actively sabotaged". Given that most unsupported platforms have only a very small user base who care about Python, I doubt that we'll be inundated with bug reports. If an occasional one comes through, closing it with a reference to PEP 11 seems simple enough.
Given that the intended process is that a core dev sponsor must be found before support can be (re)instated, it makes sense to add a reminder to this section of the PEP.
vstinner commentedon Nov 12, 2025
Emscripten is now supported in Tier-3. Can we close this issue @brettcannon?
brettcannon commentedon Nov 12, 2025
No because the base question still exists the next time a platform gets dropped.
gpshead commentedon Nov 29, 2025
FWIW I'm in favor of just changing the wording to suggest the build warn at most if it is easy to do so for things that were once a tiered platform but no longer are. We clearly have a lot of unsupported non-tier / never-tiered platforms that people keep CPython working on without a need to patch out some extra-effort build failure.
encukou commentedon Dec 1, 2025
It might be better to put calls for maintainers in the relevant release notes than in build output.
As I now see it, support promises -- ours or others' -- get added “on top” of what's in the repo itself. Release notes are fittingly specific to the CPython core team.