説明
A typical script or notebook using GluonTS begins as follows:
from gluonts.dataset.repository.datasets import get_dataset, dataset_recipes
from gluonts.dataset.common import ListDataset
from gluonts.dataset.field_names import FieldName
from gluonts.evaluation import Evaluator
from gluonts.evaluation.backtest import make_evaluation_predictions
from gluonts.model.simple_feedforward import SimpleFeedForwardEstimator
from gluonts.mx.trainer import Trainer
This type of deep import paths makes it hard to remember what-is-where, and forces one to have lots of different import lines to do anything. One could could instead have:
from gluonts.dataset import get_dataset, dataset_recipes, ListDataset, FieldName
from gluonts.evaluation import Evaluator, make_evaluation_predictions
from gluonts.mx import SimpleFeedForwardEstimator, Trainer
This makes the package more pleasant to use, especially in interactive mode.
One could even shorten it further and expose almost everything from gluonts directly (although it is arguable whether this would be good or not), but not everything: to keep some optional dependencies (MXNet, PyTorch, ...), some components will need to be imported from different sub-packages.
Note: in the above I’m moving SimpleFeedForwardEstimator to gluonts.mx (from gluonts.model). We can keep the gluonts.model import path around (maybe deprecate it?) since all models there are currently MXNet-based.
Docs driven change
Since GluonTS code-base is pretty huge and messy by now, it might be hard to do all the changes at once. One way to proceed is to let example and documentation code drive the change: we can use scripts and notebooks there to identify what is commonly imported, shorten their paths, and make sure that they work.
Backward compatible
The above changes could be done in a backward-compatible manner, so no code should be moved. Following the changes, we should also adjust imports in all tests, examples scripts and notebooks, and documentation, so that the “recommended” import paths are always guaranteed to be available.
Optional: deprecate importing from deeper modules
We could also deprecate importing directly from the modules which are more than two levels down the path: in this way once people stop importing from there we can allow ourselves reorganizing the code as we wish (e.g. renaming modules, merging modules, moving definitions).
However I’m not sure how easy this is, i.e. how easy it is to have the following distinction:
from gluonts.dataset import ListDataset # silently imports
from gluonts.dataset.common import ListDataset # prints deprecation warning