No std

[Person-93]

This PR adds an std feature (enabled by default) and gates some impls behind it as stated in #3510 (comment) .

The line count is very high, but it's mostly replacing std with core or alloc.

Test cases for PyDict were using HashMap, i changed it to BTreeMap because HashMap is in std.

The doctest module is gated behind std.

[Person-93]

I think this is ready for initial review despite the failing checks.

One is caused by white-space differences in a compile-fail test. I don't know what is causing this. https://github.com/PyO3/pyo3/actions/runs/22745106403/job/65967168100?pr=5856#step:19:3685

There seems to be a bug when cargo-semver-checks is using rustc 1.94.0, i've opened an issue. obi1kenobi/cargo-semver-checks#1590

[Tpt]

Thank you very much for this!

My personal 2cents (don't take it as the PyO3 maintainers opinion): I am not convinced supporting no_std is worth the pain before having a clear idea of what supporting MicroPython C API would entail. Having a branch with an integration MVP (likely with everything outside of the most basic APIs just failing/being UBs) might be worth it before merging this change. Maybe we will discover that MicroPython is too different to make something like PyO3 work and writing a new library would make more sense.

[davidhewitt]

Thanks very much for the PR!

I have previously wondered about no_std support in the past and reached a similar opinion to @Tpt; effectively all the implementations of Python currently supported by PyO3 are all very much dependent on platform APIs being widely available (maybe with the exception of WASM, where at least allocation is still supported).

I'm definitely very open to having micropython supported, I just suspect that having the FFI part working will be much harder than this transformation. I also don't think a micropython support prototype will be blocked by lack of no_std support (It'll just make it less useful to actually deploy to microcontrollers until we land no_std as a followup?).

[Person-93]

My primary motivation for this PR is wasm support. I linked to that issue because that's what came up when i searched the issues for no_std.

[davidhewitt]

Ah ok, can you clarify the use case where this helps with wasm please?

[Person-93]

Ah ok, can you clarify the use case where this helps with wasm please?

CPython officially supports wasm targets. Rust supports wasm targets as well, but parts of std do not work right. I'd like to use no_std for wasm to avoid the rust issues.