Merge lp:~allenap/maas/lazy-module-loading into lp:~maas-committers/maas/trunk
Status: | Rejected |
---|---|
Rejected by: | MAAS Lander |
Proposed branch: | lp:~allenap/maas/lazy-module-loading |
Merge into: | lp:~maas-committers/maas/trunk |
Diff against target: |
377 lines (+292/-13) 4 files modified
src/provisioningserver/utils/__init__.py (+8/-9) src/provisioningserver/utils/lazy.py (+137/-0) src/provisioningserver/utils/tests/test_lazy.py (+145/-0) src/provisioningserver/utils/tests/test_utils.py (+2/-4) |
To merge this branch: | bzr merge lp:~allenap/maas/lazy-module-loading |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Mike Pontillo (community) | Needs Information | ||
Review via email: mp+274405@code.launchpad.net |
Commit message
A lazy module loader to take away those circular import blues.
Description of the change
This has been sitting around since June and I finally got around to finishing it off when travelling home from Seattle. This contains the module importer and an example or two of its use. There's a follow-up branch that replaces most/all of the remaining circular imports with it.
Unmerged revisions
- 4018. By Gavin Panella
-
Merge trunk, resolving minor conflicts.
- 4017. By Gavin Panella
-
Update tests and importer()'s docstring.
- 4016. By Gavin Panella
-
Actually add the tests.
- 4015. By Gavin Panella
-
Extract much of update_references() into gen_reference_
updates( ). - 4014. By Gavin Panella
-
Remove talk of changing frames; local variables can be read but not written.
- 4013. By Gavin Panella
-
Tests for lazy.find() and lazy.update_
references( ). - 4012. By Gavin Panella
-
Move the lazy module importer to a module of its own.
- 4011. By Gavin Panella
-
lazy() helper for circular imports and deferred loading, work in progress.
I think this is a novel way to solve the problem, and I think it could be a step in the right direction.
However, I'm not sure we should land it this late in 1.9. It seems risky to introduce the extra logic now. It seems you are creating "proxy" objects, and I don't fully understand how all of the proxying logic works. For example, do the objects returned by the lazy importer obey "normal" python conventions, such as returning the appropriate type when isinstance() is called?
It seems that another way to solve the circular import problem would be to import modules rather than functions at the top level, so that the specific dependencies we need aren't resolved until the correct time. But that would lead to code like:
from maasserver.models import fabric
...
def foo():
f = fabric.Fabric()
# or...
Fabric = fabric.Fabric
f = Fabric()
... which seems less than ideal. (but perhaps no worse than the extra 'import' line we have now, or writing a few hundred lines of lazy-importing code!)