-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify and document our submodule layout principles #12711
Comments
I think these questions should have easy-to-find answers for our (new) contributors and maintainers:
|
While I appreciate the effort (thanks @drammock!) I'm not convinced that strict rules are of much help here. I'd propose to decide ad-hoc on a case-by-case basis. |
I agree that for point (1) it will probably need to be case-by-case. To the extent that we can, being more descriptive/verbose in our submodule docstrings might encode this information. I think we also have some related (possibly unwritten) norms that it would be helpful to capture, e.g., for the subpoint under 1, "functions return copies of instances (or some other kind of object), whereas methods modify the instance in place." Points 2, 4, and maybe 3, I feel like we could probably at least agree on guidelines; e.g. for point 4 I've seen some software that defines classes / functions in |
I think it would be useful to clarify/discuss why the other stats functions do not get to live in their own namespace. What's the rationale behind it? Is it the number of (expected) functions?
Originally posted by @cbrnr in #12707 (comment)
The text was updated successfully, but these errors were encountered: