refactor: split error-handling code from _util
#1752
Conversation
agoose77
changed the title
_util
Codecov Report
Additional details and impacted files
|
There was a problem hiding this comment.
Yes, _util is a catch-all (because naming is hard, and I wanted to have a low barrier to making helper functions whenever we needed one). But this _errors is a good, well-defined classification.
The intention was for _util to be a dependency of most submodules, but _util itself doesn't depend on them (i.e. very early in the dependency graph). It looks like _util depends on nplikes at module-level, but all the other accesses of ak.* are inside functions—in other words, delayed—and therefore not a dependency cycle.
Similarly, nplikes only depends on ak.* inside functions, no dependency cycles when the module loads.
|
Yes, to clarify; we don't have any "broken" import cycles, but that is managed by using the two-phase module initialisation feature (and, if this weren't possible, we could still import other names within functions). Ideally, we could declare our dependencies at the top of the file with explicit imports, i.e. as a DAG. It won't always be possible to perform this split without compromising the general structure and layout of Awkward, and we don't need to pursue that level of separation. |
ak._utilhas become something of a catch-all module. Besides making_utilquite large, this also means that_utildepends on many Awkward modules, which in turn depend upon_util. Currently, we resolve this by using the module object, which can break import cycles. However, this can be improved.This PR splits out the error-handling code into an
_errorsprivate module.There is more work that can be done here, but to keep this PR small and mergeable, we can do that in another PR.