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
Because we're not defining __all__, files export many names from locations where they shouldn't be accessible.
This is compounded by ofrak.core reexporting names from submodules using star imports, leading to situations where scripts expect that system libraries like os are imported by from ofrak.core import *.
I think the lowest maintenance burden solution is enforcing __all__ usage in files.
Which files would be affected?
(almost) every python file
Does the proposed maintenance include non-doc string functional changes to the Python code?
Yes
Are you interested in implementing it yourself?
Yes
The text was updated successfully, but these errors were encountered:
I don't oppose this, but I do want to point out that if we use __all__, we will need to keep it updated every time we add new importable OFRAK components, attributes, classes, etc.
How should we ensure that it is kept up-to-date? Should there be a checkbox in every PR? A test that confirms new stuff is importable via CI?
I agree that it's not a big deal if the author needs to explicitly expose things, but it should not be assumed that contributors will know to do that without prompting from a failing test or a note in the PR template.
Arguably we should already have included such prompting, and the change associated with this issue seems like a good place to do that.
Because we're not defining
__all__
, files export many names from locations where they shouldn't be accessible.This is compounded by
ofrak.core
reexporting names from submodules using star imports, leading to situations where scripts expect that system libraries likeos
are imported byfrom ofrak.core import *
.I think the lowest maintenance burden solution is enforcing
__all__
usage in files.Which files would be affected?
(almost) every python file
Does the proposed maintenance include non-doc string functional changes to the Python code?
Yes
Are you interested in implementing it yourself?
Yes
The text was updated successfully, but these errors were encountered: