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
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.The text was updated successfully, but these errors were encountered: