You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PEP-0561 does not mention extension packages, packages that consist of just an .so file. Given that PEP-484 mentions extension modules as a use case for stub files, could the typing documentation make it more clear what the ideal layout of an extension only package is?
It appears to be valid to have a package structure like the following:
If it's a rare enough case that the recommendation should be to package it more like a multi-file package then that seems reasonable to me too. PEP-561 does allude to this when it says:
The single-file module should be refactored into a package and indicate that the package supports typing as described above.
It wasn't clear to me if this applied to single .so file projects as well. But a single .so is a single-file module so I suppose it does. I'd be happy with either approach.
To clarify, this multi-file approach would look like the following:
I'll add one detail to the package structure. A single-file extension module can contain submodules. (For example, pybind11 and nanobind have helper functions def_submodule to easily create submodules.) So in general, we can have multiple pyi files corresponding to one .so:
PEP-0561 does not mention extension packages, packages that consist of just an .so file. Given that PEP-484 mentions extension modules as a use case for stub files, could the typing documentation make it more clear what the ideal layout of an extension only package is?
It appears to be valid to have a package structure like the following:
@ethanhs suggested in python/peps#2318 that this is the correct way of doing things.
The text was updated successfully, but these errors were encountered: