Dynamic imports - for model-specific packages

[aditya0by0]

• Make model-specific packages optional #11

Note On Dynamic Imports:
Even if you write import package inside a method that’s called 100 times, Python’s import system caches it.
Because of Python’s internal import caching mechanism.
The first time, Python loads torch from disk and stores it in sys.modules.
Every subsequent import torch, even if it appears in a loop or method, simply reuses the already-loaded module.
So performance-wise, it’s almost free after the first import.

Check documentation here: https://docs.python.org/3/reference/import.html#the-module-cache

https://docs.python.org/3/faq/programming.html#why-are-modules-imported-multiple-times

Only move imports into a local scope, such as inside a function definition, if it’s necessary to solve a problem such as avoiding a circular import or are trying to reduce the initialization time of a module. This technique is especially helpful if many of the imports are unnecessary depending on how the program executes. You may also want to move imports into a function if the modules are only ever used in that function. Note that loading a module the first time may be expensive because of the one time initialization of the module, but loading a module multiple times is virtually free, costing only a couple of dictionary lookups. Even if the module name has gone out of scope, the module is probably available in sys.modules.

[sfluegel05]

Looks good. I had some trouble with reformatting (I used the github web interface to resolve mere conflicts which was a mistake), but that should be resolved now. Also, I like the trick with putting type hints in quotation marks