@pablogsal Am I correct to assume that _remote_debugging.RemoteUnwinder should be immutable and is really internal?

Yes 👍

It's only "publicly" accessible through profiling.sampling.SampleProfiler.unwinder but I don't know if it's meant to be used externally.

Is also accessible via Lib/asyncio/tools.py. What do you mean with externally? By end users?

By end users?

Yes. I wondered whether a NEWS entry was needed or not but considering it's (1) a really internal type (2) the RemoteUnwinder type and its instances are not directly accessible by the end user (or would it be possible later?), I will not write a NEWS entry for the unwinder type.

The rationale why the other types were documented is because I can access them with public functions directly, e.g., zlib.Compress is obtained by zlib.compressobj(). But for RemoteUnwinder, you need a bit more work to access an instance of that type.

Yes. I wondered whether a NEWS entry was needed or not but considering it's (1) a really internal type (2) the RemoteUnwinder type and its instances are not directly accessible by the end user (or would it be possible later?), I will not write a NEWS entry for the unwinder type.

For now is strictly private and not intented for direct usage, just via different parts of the standard library that are in turn user visible.

Can I split the PR for immutable types into those that are in _test*api and xxlimited* with those that are used in release builds?

This is up to you.