Thanks for opening your first issue here at xarray! Be sure to follow the issue template!
If you have an idea for a solution, we would really welcome a Pull Request with proposed changes.
See the Contributing Guide for more.
It may take us a while to respond here, but we really value your contribution. Contributors like you help make xarray better.
Thank you!

for reference, anything in xarray.core is private API and thus can change at any time.

What are you using xarray.core.rolling for? If this is about anything in the public API (like DatasetRolling for use as a type hint, for example), we may be able to find a way to provide a stable import path for that.

cc @max-sixty

Edit: oh, wait, I didn't notice that this only happens on python=3.11. Let me check what is actually going on here.
Edit2: I can't reproduce with

mamba create -n test python=3.12 xarray=2025.03.0; conda activate test; python -c 'import xarray.core.rolling'; conda deactivate

This always fails for me, regardless of the python version used to create the environment.

I am not using the private API directly, but it is used by linopy in expressions.py

But I see now that their latest version has the following code at the beginning :

try:
    # resolve breaking change in xarray 2025.03.0
    import xarray.computation.rolling
    from xarray.computation.rolling import DatasetRolling
except ImportError:
    import xarray.core.rolling
    from xarray.core.rolling import DatasetRolling  # type: ignore

So my issue comes down to using an outdated version of linopy.
Also I was mistaken on the fact it worked with later python version.

As suspected, that import appears to be for type hinting purposes. I guess that means we should provide a stable import path / an official way for type hinting the return values of our various operations that return intermediate objects.

@pydata/xarray, what do you think?

Makes sense to me.

Yes, good idea. What's the best place for that? xarray.types / xarray.api?

types has a lot of internal stuff too. So, somewhere else would be good!

xarray.typing?

Hi all,

I've recently joined B-Open and started working with xarray and would love to get more involved as a contributor.
I thought implementing a typing module could be a good starting point.

I have a couple of questions to better understand how you'd approach this:

1. Would you prefer to implement the typing module as a single file (xarray/typing.py), or as a package (xarray/typing/ with an __init__.py)?
2. There are many internal types in xarray that could potentially be included, but I understand that not all of them should be exposed. Is there a recommended way to decide which types belong in the typing module? One idea I had was to include only types that are referenced in the public documentation—do you think that would be a reasonable approach?

Thanks for your help and for maintaining such a great library!

Best,
Michele

hi @micguerr-bopen !

that would be very welcome!

I think we can start with just xarray/typing.py, and start with some of the "bigger" types that aren't at the top level. things like D*Rolling, group by types — if you have the patience then looking through what used to be in xarray.core

we could add a docstring saying these are public API and can be referenced by other libraries

I'd probably choose whatever is in the docs for a first pass, and only then go through the code to see what's missing (which we should then also document)