[ENH] draft design for refactoring datatypes module - classes#6033
[ENH] draft design for refactoring datatypes module - classes#6033
datatypes module - classes#6033Conversation
|
Note to self: this would also solve the issue of documenting the mtype specifications, if we (a) do it in the class docstring, and (b) list them in the API reference. A minor issue is displaying the naming of mtypes, though this can be taken care of in the first line of the class docstring. |
|
Since |
|
hmm - good idea! |
|
do you want to try copy this, or should I do that? |
|
You can copy it - is it possible after wards for me to work on the your branch that you made? |
|
sure. Let me adapt it, and then you try to merge with your |
This PR refactors the data type specifications and converters to classes. Implements sktime/sktime#3512, related to sktime/sktime#2957. Contains: * a base class for mtypes, `BaseDatatype`, to replace the more ad-hoc dictionary design * a complete refactor of the `Table` mtype submodule to this interface * a base class for converters, `BaseConverter`, also replacing a dictionary based design * a partial refactor of the `Table` related converters to this interface * a full refactor of the public framework module with `check` and `convert` logic, in `datatypes`, to allow extensibility with this design Partial mirror in `skpro` of sktime/sktime#6033
This PR refactors the data type specifications and converters to classes. Related: sktime/sktime#3512, related to sktime/sktime#2957. Contains: * a base class for datatype examples, `BaseExample`, to replace the more ad-hoc dictionary design * a complete refactor of the `Table` and `Proba` mtype submodules to this interface * a full refactor of the public framework module with `get_example` logic, in `datatypes`, to allow extensibility with this design Partial mirror in `skpro` of sktime/sktime#6033
|
superseded by #7161 |
…ecords (#7161) This PR carries out a refactor of the `datatypes` module to `scikit-base` classes and data records, with the following benefits: * modularity and extensibility * the classes can be used as records in the documentation to store information about the container specification * programmatic soft dependency isolation, e.g., of data containers requiring soft dependencies such as `polars`, `dask`, `xarray`, `gluonts`, etc. The refactor parallels that in `skpro`, and replaces the earlier attempt in #6033. Towards #3512.
…ecords (#7161) This PR carries out a refactor of the `datatypes` module to `scikit-base` classes and data records, with the following benefits: * modularity and extensibility * the classes can be used as records in the documentation to store information about the container specification * programmatic soft dependency isolation, e.g., of data containers requiring soft dependencies such as `polars`, `dask`, `xarray`, `gluonts`, etc. The refactor parallels that in `skpro`, and replaces the earlier attempt in #6033. Towards #3512.
Implements #3512, related to #2957
This adopts the design proposed in the issue, with a class for mtypes, and a class for conversions, both being
BaseObject.The design is meant ot make the
datatypesmodule more extensible, and making it easier to manage soft dependencies in data type such asxarray,polars, ortemporianEventSet(FYI @ianspektor, @achoum).Currently in draft state for review, contains only the proposed class structure and refactor of a single mtype (
pd.DataFrame),FYI @sktime/core-developers