-
Notifications
You must be signed in to change notification settings - Fork 60
Description
Is there a specific philosophy that this repo has about using pybind11_stubgen-defined classes in the generated stubs?
At the moment, I see that this is done mainly for --numpy-array-wrap-with-annotated with pybind11_stubgen.typing_ext.FixedSize and pybind11_stubgen.typing_ext.DynamicSize("m", "n"), although I am also seeing it in #199.
My main concern with not making this choice explicit is that a lot of projects incorporating pybind11_stubgen into their builds might only include pybind11_stubgen as a build dependency and not as a required dependency of the whole project. This would mean users installing these projects would not have pybind11_stubgen installed, and type checkers would fail to resolve these expressions, in part or in full.
There are a few non-mutually exclusive options that I can think of:
- Do not use
pybind11_stubgen-defined classes at all in generated stubs. I think this is the safest default approach. - Inject definitions for these
pybind11_stubgen-defined classes into the generated stubs. Maybe asProtocols? Would this mean re-defining aFixedSizeprotocol in every file it is used in? - Allow importing from
pybind11_stubgen, with the user explicitly acknowledging that they must markpybind11_stubgenas a required dependency of their project in order to fully utilize the generated stubs.