From f624ea1d3d833aae5eabb9f9f1a0e53f1192a8a8 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Thu, 6 Nov 2025 11:53:54 -0800 Subject: [PATCH 01/10] Initial draft --- peps/pep-NNNN.rst | 119 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 peps/pep-NNNN.rst diff --git a/peps/pep-NNNN.rst b/peps/pep-NNNN.rst new file mode 100644 index 00000000000..53d233b8e01 --- /dev/null +++ b/peps/pep-NNNN.rst @@ -0,0 +1,119 @@ +PEP: +Title: WASI Support +Author: Brett Cannon +Discussions-To: Pending +Status: Draft +Type: Informational +Created: 05-Nov-2025 +Post-History: Pending +Resolution: + + +Abstract +======== + +This PEP outlines the expected support for WASI_ by CPython. +It contains enough details to know what WASI and WASI SDK version is expected to be supported for any release of CPython when official WASI support is specified in :pep:`11`. + + +Motivation +========== + +[why is this PEP necessary?] + +CPython has supported WASI according to :pep:`11` since Python 3.11. +As part of this support, CPython needs to target two different things: the WASI_ version and the `WASI SDK`_ version (both of whose development is driven by the `Bytecode Alliance`_). +The former is the specification of WASI itself while the latter is a version of clang_ with wasi-libc_ as the sysroot that allows for compiling CPython to WASI. +There is roughly an annual release cadence for new WASI versions while there's no set release cadence for WASI SDK. + +Agreeing on the WASI and WASI SDK version to support allows for clear targeting of the CPython code base towards those versions. +That lets the community set appropriate expectations as to what will (not) be considered a bug if it only manifests itself under a different WASI or WASI SDK version. +It also provides the community an overall target for WASI and WASI SDK for any specific Python version. +This is important as WASI SDK is NOT forwards- or backwards-compatible, making broad coordination so code works together important. + + +Rationale +========= + +[What do we have to consider when coming up with a spec?] + +While technically separate, CPython cannot support a version of WASI until WASI SDK supports it. +WASI versions are considered backwards-compatible with each other, but WASI SDK is NOT compatible forwards or backwards. +As such, it's important to set support expectations for a specific WASI SDK version in CPython. +Historically, the support difference between WASI SDK versions for CPython have involved settings in the ``config.site`` file that is maintained for WASI. +Support issues have come up due to bugs in WASI SDK itself. +Finally, new features being supported by WASI SDK can also cause code that wasn't previously used in a WASI build to suddenly be run which can require code updates to pass tests. + +As for WASI version support, that typically translates into what stdlib modules are (potentiallly) usable with a WASI build. +For example, WASI 0.2 added socket support and WASI 0.3.1 is scheduled to have some form of threading support. +Knowing what WASI version is supported sets expectations for what stdlib modules should be supported. + +Interpreter feature availability can be dependent on the WASI version. +For instance, until there is threading support there can't be free-threading support in WASI. +Once again, this helps set expectations of what should be working based on the target WASI version. + + +Specification +============= + +[How does it work?] + +The WASI and WASI SDK version supported by a CPython version in CI or it stable Buildbot worker (in that order of priority) when b1 is released MUST be the version to be supported for the lifetime of any Python version after this PEP is accepted. +CI takes priority over the Buildbots, when WASI is run in CI, as it is run more often and what core developers encounter first. +The WASI version and WASI SDK version supported for a Python version MUST be recorded in this PEP as an official record. + +Any updates to :pep:`11` to reflect the appropriate appropriate WASI version for the target triple for the main branch MUST be made as needed, but it does NOT require steering council approval to update. +The steering council is spared needing to approve such an update as it does not constitute a new platform and is more inline with a new OS release. + + +Designated Support +================== + +====== ==== ======== +Python WASI WASI SDK +====== ==== ======== +3.14 p1 24 +3.13 p1 24 +3.12 p1 16 +3.11 p1 16 +====== ==== ======== + + +Notes +----- + +All versions prior to Python 3.15 predate this PEP. +The version support for those versions is based on what was supported when this PEP was written. + +WASI was a tier 3 platform according to :pep:`11` for Python 3.11 and 3.12. +WASI became a tier 2 platform starting with Python 3.13. + +WASI 0.2 support has been skipped due to lack of time until it was deemed better to go straight to WASI 0.3 instead. +This is based on a recommendation from the `Bytecode Alliance`_. + + +Acknowledgements +================ + +[Thank anyone who has helped with the PEP.] + +Thanks to Joel Dice and Ben Brandt of the Python `sub-group `__ of the `guest languages SIG `__ of the `Bytecode Alliance`_ for discussing the specification of this PEP. + + +Footnotes +========= + +[A collection of footnotes cited in the PEP, and a place to list non-inline hyperlink targets.] + +.. _WASI: https://wasi.dev +.. _WASI SDK: https://github.com/WebAssembly/wasi-sdk +.. _wasi-libc: https://github.com/WebAssembly/wasi-libc +.. _clang: https://clang.llvm.org +.. _Bytecode Alliance: https://bytecodealliance.org + + +Copyright +========= + +This document is placed in the public domain or under the +CC0-1.0-Universal license, whichever is more permissive. From 8bd8e55a6e9d88bee24786ffced41d270d95de42 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Thu, 6 Nov 2025 15:21:18 -0800 Subject: [PATCH 02/10] Minor touch-ups --- peps/pep-NNNN.rst | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/peps/pep-NNNN.rst b/peps/pep-NNNN.rst index 53d233b8e01..93a0c817b50 100644 --- a/peps/pep-NNNN.rst +++ b/peps/pep-NNNN.rst @@ -27,9 +27,9 @@ The former is the specification of WASI itself while the latter is a version of There is roughly an annual release cadence for new WASI versions while there's no set release cadence for WASI SDK. Agreeing on the WASI and WASI SDK version to support allows for clear targeting of the CPython code base towards those versions. -That lets the community set appropriate expectations as to what will (not) be considered a bug if it only manifests itself under a different WASI or WASI SDK version. -It also provides the community an overall target for WASI and WASI SDK for any specific Python version. -This is important as WASI SDK is NOT forwards- or backwards-compatible, making broad coordination so code works together important. +This lets the community set appropriate expectations as to what will (not) be considered a bug if it only manifests itself under a different WASI or WASI SDK version. +It also provides the community an overall target for WASI and WASI SDK for any specific Python version when building other software like libraries. +This is important as WASI SDK is NOT forwards- or backwards-compatible, making broad coordination important so code works together. Rationale @@ -44,7 +44,7 @@ Historically, the support difference between WASI SDK versions for CPython have Support issues have come up due to bugs in WASI SDK itself. Finally, new features being supported by WASI SDK can also cause code that wasn't previously used in a WASI build to suddenly be run which can require code updates to pass tests. -As for WASI version support, that typically translates into what stdlib modules are (potentiallly) usable with a WASI build. +As for WASI version support, that typically translates into what stdlib modules are (potentially) usable with a WASI build. For example, WASI 0.2 added socket support and WASI 0.3.1 is scheduled to have some form of threading support. Knowing what WASI version is supported sets expectations for what stdlib modules should be supported. @@ -58,17 +58,23 @@ Specification [How does it work?] -The WASI and WASI SDK version supported by a CPython version in CI or it stable Buildbot worker (in that order of priority) when b1 is released MUST be the version to be supported for the lifetime of any Python version after this PEP is accepted. -CI takes priority over the Buildbots, when WASI is run in CI, as it is run more often and what core developers encounter first. +The WASI and WASI SDK version supported by a CPython version in CI or its stable Buildbot builder when b1 is released MUST be the version to be supported for the lifetime of that Python version after this PEP is accepted. +CI takes priority over the Buildbot builder as it is run more often and what core developers encounter first. +This also protects against any lag between the versions tested against in CI and the Buildbot builder as CI is likely to be updated first. + The WASI version and WASI SDK version supported for a Python version MUST be recorded in this PEP as an official record. -Any updates to :pep:`11` to reflect the appropriate appropriate WASI version for the target triple for the main branch MUST be made as needed, but it does NOT require steering council approval to update. -The steering council is spared needing to approve such an update as it does not constitute a new platform and is more inline with a new OS release. +Any updates to :pep:`11` to reflect the appropriate WASI version for the target triple for the main branch MUST be made as needed, but it does NOT require steering council approval to update. +The steering council is spared needing to approve such an update as it does not constitute a new platform and is more in line with a new OS release which currently does not require steering council approval. Designated Support ================== +Note that while WASI SDK in some places lists both a major and minor version, in actuality the minor version has never been set to anything other than ``0`` and there's an expectation that `any minor version will be ABI compatible with the overall major version `__. +As well, the WASI community only refers to WASI SDK versions by their major version due to there having never been a minor release. +Subsequently, this PEP only records the major version of WASI SDK until such time that there's a need to record a minor version. + ====== ==== ======== Python WASI WASI SDK ====== ==== ======== @@ -91,6 +97,8 @@ WASI became a tier 2 platform starting with Python 3.13. WASI 0.2 support has been skipped due to lack of time until it was deemed better to go straight to WASI 0.3 instead. This is based on a recommendation from the `Bytecode Alliance`_. +WASI SDK 26 and 27 have a `bug `__ which causes CPython to hang in certain situations, and so they have been skipped. + Acknowledgements ================ From bc92ba8c492d8b44446bf4985f728d5694078fe8 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Thu, 6 Nov 2025 15:29:15 -0800 Subject: [PATCH 03/10] Simplify the case of when CI and the buildbots differ --- peps/pep-NNNN.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/peps/pep-NNNN.rst b/peps/pep-NNNN.rst index 93a0c817b50..5ea9bfef857 100644 --- a/peps/pep-NNNN.rst +++ b/peps/pep-NNNN.rst @@ -59,8 +59,7 @@ Specification [How does it work?] The WASI and WASI SDK version supported by a CPython version in CI or its stable Buildbot builder when b1 is released MUST be the version to be supported for the lifetime of that Python version after this PEP is accepted. -CI takes priority over the Buildbot builder as it is run more often and what core developers encounter first. -This also protects against any lag between the versions tested against in CI and the Buildbot builder as CI is likely to be updated first. +If there is a discrepancy between CI and the Buildbot builder for some reason, the WASI maintainers as specified by :pep:`11` will choose which sets of versions will be designated as the versions to support. The WASI version and WASI SDK version supported for a Python version MUST be recorded in this PEP as an official record. From 9e3781af1d6eaebd54d238b8cc48ec52af1cee0c Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Thu, 6 Nov 2025 16:17:10 -0800 Subject: [PATCH 04/10] Tweak some wording --- peps/pep-NNNN.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/peps/pep-NNNN.rst b/peps/pep-NNNN.rst index 5ea9bfef857..8928a90d277 100644 --- a/peps/pep-NNNN.rst +++ b/peps/pep-NNNN.rst @@ -23,13 +23,13 @@ Motivation CPython has supported WASI according to :pep:`11` since Python 3.11. As part of this support, CPython needs to target two different things: the WASI_ version and the `WASI SDK`_ version (both of whose development is driven by the `Bytecode Alliance`_). -The former is the specification of WASI itself while the latter is a version of clang_ with wasi-libc_ as the sysroot that allows for compiling CPython to WASI. +The former is the specification of WASI itself while the latter is a version of clang_ with a specific version of wasi-libc_ as the sysroot that allows for compiling CPython to WASI. There is roughly an annual release cadence for new WASI versions while there's no set release cadence for WASI SDK. -Agreeing on the WASI and WASI SDK version to support allows for clear targeting of the CPython code base towards those versions. +Agreeing on which WASI and WASI SDK versions to support allows for clear targeting of the CPython code base towards those versions. This lets the community set appropriate expectations as to what will (not) be considered a bug if it only manifests itself under a different WASI or WASI SDK version. It also provides the community an overall target for WASI and WASI SDK for any specific Python version when building other software like libraries. -This is important as WASI SDK is NOT forwards- or backwards-compatible, making broad coordination important so code works together. +This is important as WASI SDK is NOT forwards- or backwards-compatible in the ABI it produces, making broad coordination important so code works together. Rationale @@ -38,7 +38,7 @@ Rationale [What do we have to consider when coming up with a spec?] While technically separate, CPython cannot support a version of WASI until WASI SDK supports it. -WASI versions are considered backwards-compatible with each other, but WASI SDK is NOT compatible forwards or backwards. +WASI versions are considered backwards-compatible with each other, but WASI SDK is NOT compatible forwards or backwards in terms of the ABI it produces. As such, it's important to set support expectations for a specific WASI SDK version in CPython. Historically, the support difference between WASI SDK versions for CPython have involved settings in the ``config.site`` file that is maintained for WASI. Support issues have come up due to bugs in WASI SDK itself. From c14ccce9bb11e4d5f8140542c45324475e8ab3b4 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Fri, 7 Nov 2025 14:54:11 -0800 Subject: [PATCH 05/10] Updates based on feedback --- peps/pep-NNNN.rst | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/peps/pep-NNNN.rst b/peps/pep-NNNN.rst index 8928a90d277..a46c56ef33f 100644 --- a/peps/pep-NNNN.rst +++ b/peps/pep-NNNN.rst @@ -29,7 +29,11 @@ There is roughly an annual release cadence for new WASI versions while there's n Agreeing on which WASI and WASI SDK versions to support allows for clear targeting of the CPython code base towards those versions. This lets the community set appropriate expectations as to what will (not) be considered a bug if it only manifests itself under a different WASI or WASI SDK version. It also provides the community an overall target for WASI and WASI SDK for any specific Python version when building other software like libraries. -This is important as WASI SDK is NOT forwards- or backwards-compatible in the ABI it produces, making broad coordination important so code works together. +This is important as WASI SDK is NOT forwards- or backwards-compatible due to the ABI of wasi-libc not making any compatibility guarantees, making broad coordination important so code works together. + +This coordination and recording around version targets can be important in situations where the selected versions is non-obvious. +For example, WASI SDK 26 and 27 have a `bug `__ which cause CPython to hang in certain situations (including exiting the REPL). +Because the bug is in thread support code it wouldn't necessarily be obvious to others in the community that CPython will not target those versions and thus 3rd-party code shouldn't bother with those versions as well. Rationale @@ -38,7 +42,7 @@ Rationale [What do we have to consider when coming up with a spec?] While technically separate, CPython cannot support a version of WASI until WASI SDK supports it. -WASI versions are considered backwards-compatible with each other, but WASI SDK is NOT compatible forwards or backwards in terms of the ABI it produces. +WASI versions are considered backwards-compatible with each other, but WASI SDK is NOT compatible forwards or backwards thanks to wasi-libc not having ABI compatibility guarantees. As such, it's important to set support expectations for a specific WASI SDK version in CPython. Historically, the support difference between WASI SDK versions for CPython have involved settings in the ``config.site`` file that is maintained for WASI. Support issues have come up due to bugs in WASI SDK itself. @@ -62,6 +66,8 @@ The WASI and WASI SDK version supported by a CPython version in CI or its stable If there is a discrepancy between CI and the Buildbot builder for some reason, the WASI maintainers as specified by :pep:`11` will choose which sets of versions will be designated as the versions to support. The WASI version and WASI SDK version supported for a Python version MUST be recorded in this PEP as an official record. +If for some reason a supported version needs to change after being recorded, a note will be made as to when and why the change was made. +Such a change is at the discretion of the maintainers of WASI support as listed in :pep:`11` and does not require steering council approval. Any updates to :pep:`11` to reflect the appropriate WASI version for the target triple for the main branch MUST be made as needed, but it does NOT require steering council approval to update. The steering council is spared needing to approve such an update as it does not constitute a new platform and is more in line with a new OS release which currently does not require steering council approval. @@ -77,10 +83,10 @@ Subsequently, this PEP only records the major version of WASI SDK until such tim ====== ==== ======== Python WASI WASI SDK ====== ==== ======== -3.14 p1 24 -3.13 p1 24 -3.12 p1 16 -3.11 p1 16 +3.14 0.1 24 +3.13 0.1 24 +3.12 0.1 16 +3.11 0.1 16 ====== ==== ======== @@ -93,7 +99,7 @@ The version support for those versions is based on what was supported when this WASI was a tier 3 platform according to :pep:`11` for Python 3.11 and 3.12. WASI became a tier 2 platform starting with Python 3.13. -WASI 0.2 support has been skipped due to lack of time until it was deemed better to go straight to WASI 0.3 instead. +WASI 0.2 support has been skipped due to lack of time, to the point that it was deemed better to go straight to WASI 0.3 instead. This is based on a recommendation from the `Bytecode Alliance`_. WASI SDK 26 and 27 have a `bug `__ which causes CPython to hang in certain situations, and so they have been skipped. From 410b19bf4f51ccf561beceebc538d03b50628acd Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Wed, 12 Nov 2025 15:15:08 -0800 Subject: [PATCH 06/10] Make it harder to change the WASI version support --- peps/pep-NNNN.rst | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/peps/pep-NNNN.rst b/peps/pep-NNNN.rst index a46c56ef33f..22ff1f19551 100644 --- a/peps/pep-NNNN.rst +++ b/peps/pep-NNNN.rst @@ -66,8 +66,13 @@ The WASI and WASI SDK version supported by a CPython version in CI or its stable If there is a discrepancy between CI and the Buildbot builder for some reason, the WASI maintainers as specified by :pep:`11` will choose which sets of versions will be designated as the versions to support. The WASI version and WASI SDK version supported for a Python version MUST be recorded in this PEP as an official record. -If for some reason a supported version needs to change after being recorded, a note will be made as to when and why the change was made. + +If for some reason a supported WASI SDK version needs to change after being recorded, a note will be made as to when and why the change was made. Such a change is at the discretion of the maintainers of WASI support as listed in :pep:`11` and does not require steering council approval. +The expectation, though, is that such a change SHOULD NOT occur. + +Changing the WASI version MUST NOT occur UNLESS the steering council approves it. +This is due to the increased support burden for new WASI versions and the shift in expectations of what CPython would support. Any updates to :pep:`11` to reflect the appropriate WASI version for the target triple for the main branch MUST be made as needed, but it does NOT require steering council approval to update. The steering council is spared needing to approve such an update as it does not constitute a new platform and is more in line with a new OS release which currently does not require steering council approval. From 084ac1765e2fb5783b7531fde174ee570b50c364 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Fri, 5 Dec 2025 14:28:28 -0800 Subject: [PATCH 07/10] Take a PEP number --- peps/pep-8108.rst | 173 ++++++++++++++++++++++++++++++++++++++++++++++ peps/pep-NNNN.rst | 137 ------------------------------------ 2 files changed, 173 insertions(+), 137 deletions(-) create mode 100644 peps/pep-8108.rst delete mode 100644 peps/pep-NNNN.rst diff --git a/peps/pep-8108.rst b/peps/pep-8108.rst new file mode 100644 index 00000000000..b0672435a8d --- /dev/null +++ b/peps/pep-8108.rst @@ -0,0 +1,173 @@ +PEP: 8108 +Title: WASI Support +Author: Brett Cannon +Discussions-To: Pending +Status: Draft +Type: Informational +Created: 05-Nov-2025 +Post-History: Pending +Resolution: + + +Abstract +======== + +This PEP outlines the expected support for WASI_ by CPython. It contains enough +details to know what WASI and WASI SDK version is expected to be supported for +any release of CPython while official WASI support is specified in :pep:`11`. + + +Motivation +========== + +CPython has supported WASI according to :pep:`11` since Python 3.11. As part of +this support, CPython needs to target two different things: the WASI_ version +and the `WASI SDK`_ version (both of whose development is driven by the +`Bytecode Alliance`_). The former is the specification of WASI itself while the +latter is a version of clang_ with a specific version of wasi-libc_ as the +sysroot that allows for compiling CPython to WASI. There is roughly an annual +release cadence for new WASI versions while there's no set release cadence for +WASI SDK. + +Agreeing on which WASI and WASI SDK versions to support allows for clear +targeting of the CPython code base towards those versions. This also lets the +community set appropriate expectations as to what will (not) be considered a +bug if it only manifests itself under a certain WASI or WASI SDK version. It +also provides the community an overall target for WASI and WASI SDK for any +specific Python version when building other software like libraries. This is +important as WASI SDK is NOT forwards- or backwards-compatible due to the ABI +of wasi-libc not making any compatibility guarantees, making broad coordination +important so code works together. + +This coordination and recording around version targets can be important in +situations where the selected versions is non-obvious. For example, WASI SDK 26 +and 27 have a `bug `__ +which cause CPython to hang in certain situations (including exiting the REPL). +Because the bug is in thread support code it wouldn't necessarily be obvious to +others in the community that CPython will not target those versions and thus +3rd-party code should also avoid those versions. + + +Rationale +========= + +While technically separate, CPython cannot support a version of WASI until WASI +SDK supports it. WASI versions are considered backwards-compatible with each +other, but WASI SDK is NOT compatible forwards or backwards thanks to wasi-libc +not having ABI compatibility guarantees. As such, it's important to set support +expectations for a specific WASI SDK version in CPython. Historically, the +support difference between WASI SDK versions for CPython have involved settings +in the ``config.site`` file that is maintained for WASI. Support issues have +come up due to bugs in WASI SDK itself. Finally, new features being supported +by WASI SDK can also cause code that wasn't previously used in a WASI build to +suddenly be run which can require code updates to pass tests. + +As for WASI version support, that typically translates into what stdlib modules +are (potentially) usable with a WASI build. For example, WASI 0.2 added socket +support and WASI 0.3.1 is scheduled to have some form of threading support. +Knowing what WASI version is supported sets expectations for what stdlib +modules should be supported. + +Interpreter feature availability can be dependent on the WASI version. For +instance, until there is threading support there can't be free-threading +support in WASI. Once again, this helps set expectations of what should be +working based on the target WASI version. + + +Specification +============= + +The WASI and WASI SDK version supported by a CPython version in CI or its +stable Buildbot builder when b1 is released MUST be the version to be supported +for the lifetime of that Python version after this PEP is accepted. If there is +a discrepancy between CI and the Buildbot builder for some reason, the WASI +maintainers as specified by :pep:`11` will choose which sets of versions will +be designated as the versions to support. + +The WASI version and WASI SDK version supported for a Python version MUST be +recorded in :pep:`11` as an official record. + +If for some reason a supported WASI SDK version needs to change after being +recorded, a note will be made in :pep:`11` as to when and why the change was +made. Such a change is at the discretion of the maintainers of WASI support as +listed in :pep:`11` and does not require steering council approval. The +expectation, though, is that such a change SHOULD NOT occur. + +Changing the WASI version after it has been recorded MUST NOT occur UNLESS the +steering council approves it. This is due to the increased support burden for +new WASI versions and the shift in expectations of what CPython would support +when support expectations have already been set. + +Any updates to :pep:`11` to reflect the appropriate WASI version for the target +triple for the main branch MUST be made as needed, but it does NOT require +steering council approval to update. The steering council is spared needing to +approve such an update as it does not constitute a new platform and is more in +line with a new OS release which currently does not require steering council +approval. + + +Designated Support +================== + +Note that while WASI SDK in some places lists both a major and minor version, +in actuality the minor version has never been set to anything other than ``0`` +and there's an expectation that +`any minor version will be ABI compatible with the overall major version `__. +As well, the WASI community only refers to WASI SDK versions by their major +version due to there having never been a minor release. Subsequently, this PEP +only records the major version of WASI SDK until such time that there's a need +to record a minor version. + +====== ==== ======== +Python WASI WASI SDK +====== ==== ======== +3.14 0.1 24 +3.13 0.1 24 +3.12 0.1 16 +3.11 0.1 16 +====== ==== ======== + + +Notes +----- + +All versions prior to Python 3.15 predate this PEP. The version support for +those versions is based on what was supported when this PEP was written. + +WASI was a tier 3 platform according to :pep:`11` for Python 3.11 and 3.12. +WASI became a tier 2 platform starting with Python 3.13. + +WASI 0.2 support has been skipped due to lack of time, to the point that it was +deemed better to go straight to WASI 0.3 instead. This is based on a +recommendation from the `Bytecode Alliance`_. + +WASI SDK 26 and 27 have a +`bug `__ which causes +CPython to hang in certain situations, and so they have been skipped. + + +Acknowledgements +================ + +Thanks to Joel Dice and Ben Brandt of the Python +`sub-group `__ +of the +`guest languages SIG `__ +of the `Bytecode Alliance`_ for discussing the specification of this PEP. + + +Footnotes +========= + +.. _WASI: https://wasi.dev +.. _WASI SDK: https://github.com/WebAssembly/wasi-sdk +.. _wasi-libc: https://github.com/WebAssembly/wasi-libc +.. _clang: https://clang.llvm.org +.. _Bytecode Alliance: https://bytecodealliance.org + + +Copyright +========= + +This document is placed in the public domain or under the +CC0-1.0-Universal license, whichever is more permissive. diff --git a/peps/pep-NNNN.rst b/peps/pep-NNNN.rst deleted file mode 100644 index 22ff1f19551..00000000000 --- a/peps/pep-NNNN.rst +++ /dev/null @@ -1,137 +0,0 @@ -PEP: -Title: WASI Support -Author: Brett Cannon -Discussions-To: Pending -Status: Draft -Type: Informational -Created: 05-Nov-2025 -Post-History: Pending -Resolution: - - -Abstract -======== - -This PEP outlines the expected support for WASI_ by CPython. -It contains enough details to know what WASI and WASI SDK version is expected to be supported for any release of CPython when official WASI support is specified in :pep:`11`. - - -Motivation -========== - -[why is this PEP necessary?] - -CPython has supported WASI according to :pep:`11` since Python 3.11. -As part of this support, CPython needs to target two different things: the WASI_ version and the `WASI SDK`_ version (both of whose development is driven by the `Bytecode Alliance`_). -The former is the specification of WASI itself while the latter is a version of clang_ with a specific version of wasi-libc_ as the sysroot that allows for compiling CPython to WASI. -There is roughly an annual release cadence for new WASI versions while there's no set release cadence for WASI SDK. - -Agreeing on which WASI and WASI SDK versions to support allows for clear targeting of the CPython code base towards those versions. -This lets the community set appropriate expectations as to what will (not) be considered a bug if it only manifests itself under a different WASI or WASI SDK version. -It also provides the community an overall target for WASI and WASI SDK for any specific Python version when building other software like libraries. -This is important as WASI SDK is NOT forwards- or backwards-compatible due to the ABI of wasi-libc not making any compatibility guarantees, making broad coordination important so code works together. - -This coordination and recording around version targets can be important in situations where the selected versions is non-obvious. -For example, WASI SDK 26 and 27 have a `bug `__ which cause CPython to hang in certain situations (including exiting the REPL). -Because the bug is in thread support code it wouldn't necessarily be obvious to others in the community that CPython will not target those versions and thus 3rd-party code shouldn't bother with those versions as well. - - -Rationale -========= - -[What do we have to consider when coming up with a spec?] - -While technically separate, CPython cannot support a version of WASI until WASI SDK supports it. -WASI versions are considered backwards-compatible with each other, but WASI SDK is NOT compatible forwards or backwards thanks to wasi-libc not having ABI compatibility guarantees. -As such, it's important to set support expectations for a specific WASI SDK version in CPython. -Historically, the support difference between WASI SDK versions for CPython have involved settings in the ``config.site`` file that is maintained for WASI. -Support issues have come up due to bugs in WASI SDK itself. -Finally, new features being supported by WASI SDK can also cause code that wasn't previously used in a WASI build to suddenly be run which can require code updates to pass tests. - -As for WASI version support, that typically translates into what stdlib modules are (potentially) usable with a WASI build. -For example, WASI 0.2 added socket support and WASI 0.3.1 is scheduled to have some form of threading support. -Knowing what WASI version is supported sets expectations for what stdlib modules should be supported. - -Interpreter feature availability can be dependent on the WASI version. -For instance, until there is threading support there can't be free-threading support in WASI. -Once again, this helps set expectations of what should be working based on the target WASI version. - - -Specification -============= - -[How does it work?] - -The WASI and WASI SDK version supported by a CPython version in CI or its stable Buildbot builder when b1 is released MUST be the version to be supported for the lifetime of that Python version after this PEP is accepted. -If there is a discrepancy between CI and the Buildbot builder for some reason, the WASI maintainers as specified by :pep:`11` will choose which sets of versions will be designated as the versions to support. - -The WASI version and WASI SDK version supported for a Python version MUST be recorded in this PEP as an official record. - -If for some reason a supported WASI SDK version needs to change after being recorded, a note will be made as to when and why the change was made. -Such a change is at the discretion of the maintainers of WASI support as listed in :pep:`11` and does not require steering council approval. -The expectation, though, is that such a change SHOULD NOT occur. - -Changing the WASI version MUST NOT occur UNLESS the steering council approves it. -This is due to the increased support burden for new WASI versions and the shift in expectations of what CPython would support. - -Any updates to :pep:`11` to reflect the appropriate WASI version for the target triple for the main branch MUST be made as needed, but it does NOT require steering council approval to update. -The steering council is spared needing to approve such an update as it does not constitute a new platform and is more in line with a new OS release which currently does not require steering council approval. - - -Designated Support -================== - -Note that while WASI SDK in some places lists both a major and minor version, in actuality the minor version has never been set to anything other than ``0`` and there's an expectation that `any minor version will be ABI compatible with the overall major version `__. -As well, the WASI community only refers to WASI SDK versions by their major version due to there having never been a minor release. -Subsequently, this PEP only records the major version of WASI SDK until such time that there's a need to record a minor version. - -====== ==== ======== -Python WASI WASI SDK -====== ==== ======== -3.14 0.1 24 -3.13 0.1 24 -3.12 0.1 16 -3.11 0.1 16 -====== ==== ======== - - -Notes ------ - -All versions prior to Python 3.15 predate this PEP. -The version support for those versions is based on what was supported when this PEP was written. - -WASI was a tier 3 platform according to :pep:`11` for Python 3.11 and 3.12. -WASI became a tier 2 platform starting with Python 3.13. - -WASI 0.2 support has been skipped due to lack of time, to the point that it was deemed better to go straight to WASI 0.3 instead. -This is based on a recommendation from the `Bytecode Alliance`_. - -WASI SDK 26 and 27 have a `bug `__ which causes CPython to hang in certain situations, and so they have been skipped. - - -Acknowledgements -================ - -[Thank anyone who has helped with the PEP.] - -Thanks to Joel Dice and Ben Brandt of the Python `sub-group `__ of the `guest languages SIG `__ of the `Bytecode Alliance`_ for discussing the specification of this PEP. - - -Footnotes -========= - -[A collection of footnotes cited in the PEP, and a place to list non-inline hyperlink targets.] - -.. _WASI: https://wasi.dev -.. _WASI SDK: https://github.com/WebAssembly/wasi-sdk -.. _wasi-libc: https://github.com/WebAssembly/wasi-libc -.. _clang: https://clang.llvm.org -.. _Bytecode Alliance: https://bytecodealliance.org - - -Copyright -========= - -This document is placed in the public domain or under the -CC0-1.0-Universal license, whichever is more permissive. From c605550200e5c7533af0ac516a5db7137c109e3d Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Fri, 5 Dec 2025 14:58:07 -0800 Subject: [PATCH 08/10] Add CODEOWNERS --- .github/CODEOWNERS | 2 ++ peps/{pep-8108.rst => pep-0816.rst} | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) rename peps/{pep-8108.rst => pep-0816.rst} (99%) diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index d2eb5d62ab4..a0a6ab363d9 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -687,8 +687,10 @@ peps/pep-0808.rst @FFY00 peps/pep-0809.rst @zooba peps/pep-0810.rst @pablogsal @DinoV @Yhg1s peps/pep-0811.rst @sethmlarson @gpshead +# ... peps/pep-0814.rst @vstinner @corona10 peps/pep-0815.rst @emmatyping +peps/pep-0816.rst @brettcannon # ... peps/pep-2026.rst @hugovk # ... diff --git a/peps/pep-8108.rst b/peps/pep-0816.rst similarity index 99% rename from peps/pep-8108.rst rename to peps/pep-0816.rst index b0672435a8d..389a1a3ecb3 100644 --- a/peps/pep-8108.rst +++ b/peps/pep-0816.rst @@ -1,4 +1,4 @@ -PEP: 8108 +PEP: 816 Title: WASI Support Author: Brett Cannon Discussions-To: Pending From 79673b45cec20f398b69557a3bc34e6a0267a942 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Fri, 5 Dec 2025 15:02:42 -0800 Subject: [PATCH 09/10] Make the linter happy --- peps/pep-0816.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/peps/pep-0816.rst b/peps/pep-0816.rst index 389a1a3ecb3..d9087ad5196 100644 --- a/peps/pep-0816.rst +++ b/peps/pep-0816.rst @@ -6,7 +6,6 @@ Status: Draft Type: Informational Created: 05-Nov-2025 Post-History: Pending -Resolution: Abstract From 5cbd8d35a815ba0bd1c994107dd4b613b8135af9 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Mon, 8 Dec 2025 09:14:07 -0800 Subject: [PATCH 10/10] Update peps/pep-0816.rst Co-authored-by: Jelle Zijlstra --- peps/pep-0816.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/peps/pep-0816.rst b/peps/pep-0816.rst index d9087ad5196..333cc0f6f95 100644 --- a/peps/pep-0816.rst +++ b/peps/pep-0816.rst @@ -39,7 +39,7 @@ of wasi-libc not making any compatibility guarantees, making broad coordination important so code works together. This coordination and recording around version targets can be important in -situations where the selected versions is non-obvious. For example, WASI SDK 26 +situations where the selected version is non-obvious. For example, WASI SDK 26 and 27 have a `bug `__ which cause CPython to hang in certain situations (including exiting the REPL). Because the bug is in thread support code it wouldn't necessarily be obvious to