Usage of pyo3-macros within PyO3's main crate makes development harder

[davidhewitt]

I'd gotten used to a development workflow for our macro codebase where using cargo expand I would examine the macro output for a toy crate and decide what to change / debug what's gone wrong.

While streaming today to build #3847 I found that since we've now added the Coroutine code to the main crate, which uses all of #[pyfunction], #[pyclass] and #[pymethods] inside the crate itself, if those macros are broken the compilation will halt in the main crate. This breaks my development workflow. 😢 It was only late on the stream that I realised this was the cause.

I wonder if this is a good reason to discuss whether we should split the PyO3 crate further, into e.g. pyo3-core, pyo3-types, and pyo3-async. That way a toy snippet could import directly from pyo3-core and pyo3-types.

Or we could just add a feature gate back on the async code. 🤔

[adamreichold]

A default-on feature gate seems the more reasonable approach IMHO.

[davidhewitt]

I wonder, for the moment should we call the feature experimental-async? We have quite a few finishing pieces of the implementation which doesn't look like it will merge in time for 0.21.