Remove errors when type annotations used without experimental-inspect

[tbates-redarc]

I want to be able to build with the experimental-inspect feature enabled for generating type stubs, but without it for the release build of my extension. It reduces the extension DLL from 7MB to 6MB, and since I ship the generated type stubs anyway, there's no need to include this extra data in the binary.

However, trying to include type information in the #[pyo3(signature = ...)] annotations gives errors when building without experimental-inspect. Trying to conditionally compile the type information seems to be impossible, because pyo3's macros don't appear to see annotations inside #[cfg_attr(feature = "experimental-inspect", pyo3(signature = ...))] ("error: cannot find attribute pyo3 in this scope") and do appear to see them even when protected by #[cfg(feature = "experimental-inspect")].

Rather than try to fix the macros, which would still require me to have two copies of the signature (with and without type annotations), I thought it might be reasonable to just remove the errors, since having the extra type information there does no harm, it is still parsed by the macros and then ignored if the feature is disabled.

[Tpt]

Thank you for this. It makes sense to me.

@davidhewitt no objection on this?

May you add a changelog in newsfragments/5999.changed.md file?

[codspeed-hq]

Merging this PR will not alter performance

✅ 105 untouched benchmarks
⏩ 1 skipped benchmark¹

---

_{Comparing tbates-redarc:allow-types-always (60a9e42) with main (2078144)}

Footnotes

1. 1 benchmark was skipped, so the baseline result was used instead. If it was deleted from the codebase, click here and archive it to remove it from the performance reports. ↩

[davidhewitt]

Agreed this seems like the right approach, presumably once we remove the experimental-inspect feature gate we'll be in this state anyway.

I have been thinking in the background about what we do regarding the stub fragments in the final binary. I wonder if there's a way we can get pyo3-introspection to have a way to strip them out, so two builds of the extension are not needed?

[Tpt]

I wonder if there's a way we can get pyo3-introspection to have a way to strip them out, so two builds of the extension are not needed?

Definitely, we can do something like calling a well configured strip. But I have not checked the details so there might be some bad surprises.