Reduce memory footprint of SDK by separating namespace imports

[samschott]

Why is this feature valuable to you? Does it solve a problem you're having?
The Dropbox API and SDK cover a large range of functionality while some apps only use a small subset. This may be particularly true for some namespaces such as team and team_log which require different Dropbox subscriptions.

Importing all modules to cover the full API requires a relatively large amount of memory (~30 MB without 3rd party modules such as requests). A large fraction of this actually comes from the team_log namespace.

Describe the solution you'd like
Would it be possible to have separate classes for different namespaces and import modules only as needed? This of course would be a major change in design and may deviate from how other Dropbox SDKs handle this. Nevertheless, it may be worth considering, especially as new namespaces to support an evolving product will be added in the future.

Describe alternatives you've considered
Lazy loading of modules, at the point of use, may be an alternative.

[greg-db]

Thanks for writing this up! I can't make any promises, but I'll share this request with the team.