Skip to content
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

Decide which modules should define __all__ #876

Open
vyasr opened this issue Dec 8, 2022 · 2 comments
Open

Decide which modules should define __all__ #876

vyasr opened this issue Dec 8, 2022 · 2 comments

Comments

@vyasr
Copy link
Contributor

vyasr commented Dec 8, 2022

While refactoring I noticed that we define __all__ in some modules that are not __init__.py files representing a package. Is that something that we want to do or care about very much? I would be fine relying solely on underscore prefixes in all modules that are not packages and only implementing __all__ for package files, but I don't feel strongly about this. I just wanted to raise the question for consistency's sake.

@bdice
Copy link
Member

bdice commented Dec 8, 2022

In theory we should define __all__ for every public API in the namespace that we intend to expose it in. So maybe this is only needed for package __init__.py files, specifically like the root and migration directory.

@vyasr
Copy link
Contributor Author

vyasr commented Dec 8, 2022

I would consider publicly visible modules to also be part of the public API. They may not be how we most frequently interact with packages, but there are many packages that expose functionality that way for a variety of reasons (even synced_collections does this). So things like signac.sync and signac.diff are part of the API too I would say.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants