Merge pull request #34 from Point72/pit/remove_wrappings

Remove PyArrowDataType and pandas pydantic wrappers. …

Author: ptomecek

ccflow/exttypes/__init__.py

@@ -1,8 +1,7 @@
-from .arrow import ArrowSchema, ArrowTable, PyArrowDatatype
+from .arrow import *
 from .exprtk import *
 from .frequency import *
 from .jinja import *
-from .pandas import DataFrameWrapper, GenericPandasWrapper, SeriesWrapper, SparseNumericDataFrame
 
 # Do NOT import .polars. We don't want ccflow (without flow) to have a dependency on polars!
 from .pydantic_numpy import *

ccflow/exttypes/arrow.py

@@ -6,6 +6,8 @@
 from pydantic_core import core_schema
 from typing_extensions import Literal, Self, get_args
 
+__all__ = ("ArrowSchema", "ArrowTable", "PyArrowDatatype")
+
 
 class ArrowSchema(type):
     """A metaclass for creating Arrow schema-specific types that can be used with Generic classes"""

ccflow/exttypes/pandas.py

@@ -20,7 +20,6 @@ def test(self):
         "deltalake",
         "emails",
         "matplotlib",
-        "pandera",
         "mlflow",
         "plotly",
         "pyarrow.dataset",

ccflow/tests/exttypes/test_pandas.py

@@ -531,7 +531,7 @@ print(list(root))
 
 In the above, note that the "x" and "y" variables are passed as strings referencing other objects in the registry. When using hydra, something similar could be accomplished by using [variable interpolation](https://omegaconf.readthedocs.io/en/2.3_branch/usage.html#variable-interpolation) in OmegaConf, but there is one key difference. In hydra/omegaconf, variable interpolation makes a copy of the yaml config, so `transform.x` would point to an object that is configured the same way as `data/source1`, but it would not be pointing to the same *instance*. Thus, if changes were made to `data/source1`, they would not be reflected in `transform.x`.
 
-With the above behavior in place, especially the ability to load dictionaries of configs into the root `ModelRegistry`, the next step is to be able to load the configurations from files. Fortunately, this piece has already been solved by hydra. In particular, it allows for configurations to be split across multiple sub-directories and files, re-used in multiple places, and recombined as needed. It also provides advanced command line tools to configure your application.
+With the above behavior in place, especially the ability to load dictionaries of configs into the root `ModelRegistry`, the next step is to be able to load the configurations from files. Fortunately, this piece has already been solved by hydra. In particular, it allows for configurations to be split across multiple sub-directories and files, reused in multiple places, and recombined as needed. It also provides advanced command line tools to configure your application.
 
 While hydra is primarily concerned with loading file-based configurations into command-line applications, their [Compose API](https://hydra.cc/docs/advanced/compose_api/) provides a way to load the configs interactively in a notebook, as a special dictionary type. However, to save people the work of first loading config files into config dictionaries, and then adding those into the registry, we've provided a function to do this directly, shown below. Note that these config files are loading models which are defined in `ccflow` and `ccflow.examples`.
 

ccflow/tests/test_import.py

@@ -52,7 +52,6 @@ dependencies = [
 full = [
     "cexprtk",
     "pandas",
-    "pandera",
     "plotly",
     "polars",
     "ray",
@@ -74,7 +73,6 @@ develop = [
     "cexprtk",
     "csp>=0.0.4,<0.1",
     "pandas",
-    "pandera",
     "plotly",
     "polars",
     "ray",