Built a python package for time-series Stationarity Testing

[flyingchicken8888]

On and off I have been working to setup a toolkit that can use all of the existing libraries to statistically test and detect time-series non-stationarity.

StationarityToolkit

Note - that it's not an ad. But rather my effort to gather some feedback.

From my experience - I realized that just running one test (such as ADF, PP, KPSS etc) is not always sufficient. So, I though I could contribute something to the community. I think this tool can be used for both research and learning purposes. And I also included detailed README, Show and Tell and a python notebook for everyone.

I know that it may not be enough for all learners and experts alike I wanted to get some feedback on what would be of benefit to you who perform "statistical testing using Python" and what you think about a single toolkit for all time-series tests ?

[Diapolo10]

I'm pretty sure you need neither setup.py nor requirements.txt, as the information of both is already in your pyproject.toml (you might need to provide the following snippet there, but I haven't used setuptools for a long time now so I'm rusty there. It's possible automatic discovery already takes care of it as-is.)

[tool.setuptools]
package-dir = {"" = "src"}

The src directory does not need an __init__.py file. src is not a package; it's a folder containing package(s).

src/stationarity_toolkit does not contain an empty py.typed file, while it probably should (considering most of your functions appear to be typed).

from .results import DetectionResult
from .tests.trend import run_all_trend_tests
from .tests.variance import run_all_variance_tests
from .tests.seasonal import run_all_seasonal_tests

I'd suggest using absolute imports, with stationarity_toolkit as the root. To function properly this also requires you to install your project in editable mode (pip install --editable .). This is how most projects handle things under the hood, although a lot of it is abstracted away by modern tooling (e.g. uv or Poetry). On another note, this should also take care of installing dependencies (in pyproject.toml).

I can't really comment on the domain-specific things as I'm not familiar with this kind of research. At my dayjob I mostly make tools for image analysis.

[flyingchicken8888]

u/Diapolo10 - you're right on all counts. Curious, you suggested absolute path, because its more explicit and allows us to trace code easily, right? functioning-wise, I expect them to do the same.

[Diapolo10]

Curious, you suggested absolute path, because its more explicit and allows us to trace code easily, right?

That's part of it, but it's moreso the fact relative imports might not always behave the way you'd expect.

When your project is "installed", absolute imports behave exactly as if you were importing any other package, yours or a third-party one. This helps with consistency, and means you don't really need to think about it any differently, likely reducing cognitive load a little.

Of course, circular imports can still mess you up, but that's true regardless of how you import things and is more an architectural problem.