issue_comments

Great observation @mathause . I think there are two parts of this: - Do we want other libraries which do da.longitude to raise a mypy error? That may be a tradeoff with raising the true error on da.isel - How do we design the type hierarchy? We could add methods to DataWithCoords or add some Dataset_Or_DataArray-like type

Having methods like isel typed would be a win I think

Good point re accessors, I hadn't considered those. So sounds like raising an error on da.isel isn't possible regardless...

Yes, very much makes sense to copy the netCDF behavior.

I'll let @dcherian comment on the tradeoff. Either warning when reading or adding a prefix sound reasonable (but also probably can be separate PRs, this still seems like an improvement)

Thanks @observingClouds !

I wasn't paying attention to the original issue so this might be missing things — is there any concern that either of those are on the original zarr and we'd be removing them?

Thanks @mankoff !

Thanks @arongergely ! Great to have you as a contributor.

This has even been fixed since then, but not released. @max-sixty, would it be possible to issue a new release?

This should now be releasing! https://github.com/numbagg/numbagg/releases/tag/v0.2.2

Thanks a lot @keewis , LGTM

I'd be fine with disabling, since bottleneck doesn't seem to be actively maintained.

Though I would say it's numerically unstable rather than incorrect! I would always want it enabled, but it does make sense to default to the conservative option.

I had dreams of making numbagg into a better bottleneck — it's just as fast, much more flexible, and integrates really well with xarray. But those dreams have not come to pass (yet!).

Since numba won't support numpy HEAD in general, shall we remove it from the env instead?

Yes, I'll get to it if no one gets there first. I guess we also need to disable those tests

Thanks @mattragoza . Does numpy compute this correctly?

This is probably bottleneck: https://github.com/pydata/xarray/issues/7128

Do these reproduce after xr.set_options(use_bottleneck=False)?

Good idea! 👍

I would say that a tuple is fine, it IS an iterable of hashable ;)

Sorry, yes, I was unclear above!

How should we handle dimensions which are themselves tuples? (i.e. a really unlikely corner-case, but one that IIRC inspired some of the discussion in https://github.com/pydata/xarray/issues/4821)

My thought was to interpret a tuple as an iterable of dimensions. If we have a dimension name of a tuple, then that requires passing within an Iterable — i.e. the method(dim=[('a','b')]). Since the mypy changes around str | Iterable[Hashable], this seems better than the options I enumerated at https://github.com/pydata/xarray/issues/4821#issuecomment-766166088.

Does that make sense? V possible my writing and / or thinking is still not clear!

Yes I think this must be a numba issue, since it seems to be raising on just importing numba, and numagg doesn't do anything special there.

I find this quite confusing:

SystemError: initialization of _internal failed without raising an exception

Feels like the opposite of that "Error raised successfully" meme...

I'll raise an issue in numba and see whether anyone recognizes this

@shoyer @max-sixty do you know who has rights to change the default branch to main on codecov.io?

I just did this (and ofc happy to give you permission if it's helpful)

Though I still see the issue on main — https://app.codecov.io/gh/pydata/xarray/tree/main?displayType=list (not sure if we're expecting this to be better or not already?)

I think this should be also aligned with str | Iterable[Hashable], so maybe str | DataArray | Iterable[Hashable | DataArray]?

Good point...

IIUC (and it's been a while since I thought through this properly), this would support allowing tuples as dimension names, but forcing them to be passed within an iterable to methods (e.g.method(dim=[('a','b')]) for a dimension named ('a', 'b'). So we'd keep str | Iterable[Hashable], and still raise an error if a tuple was passed directly (i.e. method(dim=('a','b'))

ERROR: Package is too new: flox=0.5 was published on 2022-05-03 which was 12 months ago (policy is 12 months)

I guess that for "experimental" packages like this, we should have different reqs?

(Also the which was 12 months ago seems wrong?)

Thanks @headtr1ck !

Would you be up for making the change @templiert ?

LGTM. Could consider having it be True by default since most attrs will still make sense.

+1 to both the specific point and generally moving in this direction...

Even without looking at the size of the data, the dimensions of the array seem to have grown a lot!

The size of the data seems consistent with that (i.e. 2*27*4*3/2*48*8MB=125GB, though not exactly 58GB, looking at the difference in the "Array Shape" between the two images)

Does looking at the values of the dimension that's grown to size 48 help — are those possibly different, even though you don't intend them to be, and causing it to be huge (but sparse!)?

Does that make sense?

Closing as unrelated to xarray given https://github.com/pydata/xarray/discussions/7246#discussioncomment-4040351

Ref https://github.com/pydata/xarray/discussions/7246

Does import netCDF4 work? My guess is that the problem is there rather than xarray...

IIUC, and I always feel like a newcomer on this stuff — this could be useful for xarray consumers, who could write -> DataArray[Time, Width, Height]?

But without those being generic and "programmable" — i.e. being able to describe that .mean("width") removes the axis called width, it's not that useful for xarray itself?

Is that right?

Gosh, that's quite dramatic! Impressive find @hmaarrfk. (out of interest, how did you find this?)

I can see how that's quadratic when looping like that. I wonder whether using .assign(var1=1, var2=2, ...) has the same behavior?

Would be interesting to see whether this was covered by our existing asv benchmarks. Would be a good benchmark to add if we don't have one already.

I have no particular preference on which, but +0.5 on having a standard.

Also PyLance in VSCode has (temporarily, apparently) defaulted to making all imports absolute. So perhaps that will establish a standard.

Really cool @keewis !

(for others: check out https://github.com/keewis/reportlog-test/issues/1 for an example of it working!)

Do you think there's a risk something gets added back by mistake?

A galaxy brain idea is to have a lint in pre-commit which looks for ^import (foo|bar) for the libraries we should be lazy loading. Not fool proof. Or something to measure import time so we can see if it rises again.

I think you intend to close the wrong issue?

Sorry! Fixed

I am a bit skeptical - we test a large range of versions and the kinds of warnings we get can be quite different. I fear that we get too many false positives and end up wrapping everything with filterwarnings("ignore").

Yes, very fair.

Though to confirm — this is a concern for the "Warnings from the min-versions test", rather than warnings that xarray issues? Or for both?

Very nice @headtr1ck !

Nice!!

One would be tempted to think that this is due to xarray.testing and xarray.tutorial but those just move the imports one level down in tuna graphs.

Separate issue, but do these need to be imported into xarray/__init__.py? (I also can't see them in the third graph, but sounds like they're still there)

OK, let's give this a whirl!

There is still the problem that we support several outdated backends that will raise warnings, like pydap the outdated Version thingy. This will also happen in the min-deps builds.

Yes, good point, and I should have added above — it's still possible to ignore warnings at the test site explicitly (@pytest.mark.filterwarnings("ignore:foo"). So it's good, but also a chore, to mark each instance of those...

You can also just remove the example from the docstring, this is on minimal support anyway.

Great, done

Currently this raises a deprecation warning: https://github.com/pydata/xarray/blob/50301acd266cbfeb5a59c31f3ddabf2673e127cf/xarray/backends/rasterio_.py#L193

Possibly we add something to the doctest to ignore warnings? It'll be out of place in the docs though...

I can't repro the failure on the current PR v0.17.0-804-g7018b950. I'm using Python 3.9 with the latest dask.

/home/runner/micromamba/envs/xarray-tests/lib/python3.10/site-packages/dask/utils.py:366: error: Parenthesized context managers are only supported in Python 3.9 and greater [syntax] Found 1 error in 1 file (errors prevented further checking)

I'm not sure why it's raising an error for an imported module where --follow-imports=silent. Isn't that supposed to suppress errors in imports?

And weirdly, I get errors running mypy in dask latest main, but not this error!

❯ mypy --python-version 3.8 . dask/system.py:8: error: Unused "type: ignore" comment dask/widgets/__init__.py:20: error: All conditional function variants must have identical signatures [misc] dask/widgets/__init__.py:23: error: All conditional function variants must have identical signatures [misc] dask/layers.py:1322: error: Unused "type: ignore" comment dask/layers.py:1323: error: Unused "type: ignore" comment dask/array/core.py:5814: error: Argument 1 to "ndindex" has incompatible type "Tuple[int, ...]"; expected "SupportsIndex" [arg-type] dask/array/fft.py:196: error: Unused "type: ignore" comment dask/dataframe/core.py:438: error: Unused "type: ignore" comment dask/dataframe/core.py:4186: error: Unused "type: ignore" comment dask/dataframe/core.py:4197: error: Unused "type: ignore" comment dask/dataframe/core.py:4209: error: Unused "type: ignore" comment dask/dataframe/core.py:4408: error: Unused "type: ignore" comment dask/dataframe/core.py:4420: error: Unused "type: ignore" comment dask/dataframe/core.py:4425: error: Unused "type: ignore" comment dask/dataframe/groupby.py:1204: error: Unused "type: ignore" comment dask/dataframe/io/csv.py:9: error: Unused "type: ignore" comment dask/bytes/tests/test_s3.py:380: error: Unused "type: ignore" comment dask/bytes/tests/test_local.py:191: error: Unused "type: ignore" comment dask/bag/tests/test_text.py:33: error: Unused "type: ignore" comment dask/dataframe/tests/test_shuffle.py:1408: error: Unused "type: ignore" comment dask/dataframe/tests/test_shuffle.py:1409: error: Unused "type: ignore" comment dask/dataframe/tests/test_shuffle.py:1412: error: Unused "type: ignore" comment dask/diagnostics/tests/test_profiler.py:21: error: Unused "type: ignore" comment dask/tests/test_graph_manipulation.py:106: error: "tuple" is not subscriptable, use "typing.Tuple" instead [misc] Found 24 errors in 14 files (checked 243 source files)

Hmmm, these errors should be fixed in the latest version of this PR.

Sorry, my test was on main. I can rerun on this PR.

I get some errors:

``` ❯ git describe v0.17.0-798-g3599f873

❯ mypy --python-version 3.8 xarray/core/types.py:72: error: "tuple" is not subscriptable [misc] xarray/core/types.py:74: error: "tuple" is not subscriptable [misc] xarray/core/types.py:76: error: "tuple" is not subscriptable [misc] xarray/core/types.py:78: error: "list" is not subscriptable [misc] xarray/core/_reductions.py:18: error: Cannot find implementation or library stub for module named "flox" [import] xarray/core/_reductions.py:18: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports xarray/core/merge.py:43: error: "tuple" is not subscriptable [misc] xarray/core/merge.py:44: error: "tuple" is not subscriptable [misc] xarray/core/merge.py:45: error: "tuple" is not subscriptable [misc] xarray/core/groupby.py:661: error: Cannot find implementation or library stub for module named "flox.xarray" [import] xarray/backends/api.py:65: error: "dict" is not subscriptable [misc] Found 10 errors in 5 files (checked 139 source files) ```

(not sure why git describe is showing that tag but the commit hash should repro)

Ah excellent, thanks @headtr1ck

it does not complain, but I don't think it does anything with that (though I didn't verify). Also, I don't really want to issue basically empty releases just for pre-commit (even though technically feasible), so the only option I can see is indeed the status quo.

Great, thanks for chatting about it.

Unless you meant that black should be installed together with blackdoc? If that was the question: it already is, but will only be updated together with blackdoc, so now that I think of it that might actually make pinning in blackdoc redundant?

Without pinning black in additional_dependencies, which version is used? I think the issue might be that the latest version is used based on when it's installed. But that means that different people will have different versions. And so if we pin it within blackdoc, then people can't upgrade black without a new release of blackdoc. And so we're in this spot where each user needs to pin it within their .pre-commit-config.yaml.

Does pre-commit support additional_dependencies defined by the hook? I couldn't find it in https://pre-commit.com/#creating-new-hooks. That would solve this.

Otherwise I guess you could have a bot which released a new version of blackdoc pinned to each specific version of black. But the status quo seems OK too.

Ref https://github.com/pre-commit/pre-commit/issues/2082

As a great fan of blackdoc, can I ask a general question re blackdoc & pre-commit? Why not have the black dependency defined in the blackdoc requirements, so it gets installed without requiring additional-dependencies?

Is ti something to do with allowing people to use an old version of black with a new version of blackdoc, such that we don't want to have too aggressive a requirement?

Usually we do not use len(input) or x in input though. Maybe reversible container or something else exists?

We can build a list if we need a len? Or IIRC there is a Sized type — a Set but not an Iterable.

Thanks @d1mach . Could it be related to https://github.com/pydata/xarray/issues/7136 ?

That's quite an old version of xarray! Could we confirm it has similar results on a more recent version?

Excellent! Should we hit the green button?

Excellent @DanielGoman !

(not to use xarray to tout my personal projects — but re the doctest failures — running https://github.com/max-sixty/pytest-accept over them will auto-fix them, if that's helpful)

Thanks a lot @patrick-naylor !

Here's a fix of the type checker and a small suggestion (feel free to accept or reject!)

```diff commit 5dad26e19f1fb22e9a31854bac9471c5e1bec43c Author: Maximilian Roos m@maxroos.com Date: Tue Oct 4 00:26:48 2022 -0700

Ignore type on intentional error; (optional) tweak to error message

diff --git a/xarray/core/dataset.py b/xarray/core/dataset.py index ff54bd84..a3f26d26 100644 --- a/xarray/core/dataset.py +++ b/xarray/core/dataset.py @@ -5405,7 +5405,7 @@ def transpose( if (len(dims) > 0) and (isinstance(dims[0], list)): list_fix = [f"'{x}'" if isinstance(x, str) else f"{x}" for x in dims[0]] raise TypeError( - f'transpose requires dims to be passed as multiple arguments. Expected "{", ".join(list_fix)}". Received "{dims[0]}" instead' + f'transpose requires dims to be passed as multiple arguments. Expected .transpose({", ".join(list_fix)}). Received .transpose({dims[0]}) instead' )

     # Use infix_dims to check once for missing dimensions

diff --git a/xarray/tests/test_dataset.py b/xarray/tests/test_dataset.py index 6ac5ed06..8acd3798 100644 --- a/xarray/tests/test_dataset.py +++ b/xarray/tests/test_dataset.py @@ -6809,7 +6809,7 @@ def test_string_keys_typing() -> None: ds.assign(variables=mapping)

-def test_traspose_error() -> None: +def test_transpose_error() -> None: # Transpose dataset with list as argument # Should raise error ds = xr.Dataset({"foo": (("x", "y"), [[21]]), "bar": (("x", "y"), [[12]])}) @@ -6817,7 +6817,7 @@ def test_traspose_error() -> None: with pytest.raises( TypeError, match=re.escape( - "transpose requires dims to be passed as multiple arguments. Expected \"'y', 'x'\". Received \"['y', 'x']\" instead" + "transpose requires dims to be passed as multiple arguments. Expected .transpose('y', 'x'). Received .transpose(['y', 'x']) instead" ), ): - ds.transpose(["y", "x"]) + ds.transpose(["y", "x"]) # type: ignore

```

(FYI I had been the mypy person here — for my sins — but I think this is beyond my understanding — so putting an issue into mypy might be the best path forward on the cache issue...)

Very impressive and thorough @headtr1ck , thank you...

I got the same result in riscv64. One thing I could guess is that the sign bit of NaN is not kept during conversions. Some more details could be found at

Thanks for trying that. Notably, that code doesn't have xarray in. So I'm keen to be part of the solution, but it doesn't look to be a problem with xarray code specifically. Let me know if that makes sense.

Closing but please feel free to reopen

Looks excellent!

(there are a few tests commented out, not sure whether that's intentional...)

Hmmm, python seems to deal with this reasonably for its builtins:

```python In [1]: a = [1]

In [2]: b = [a]

In [3]: a.append(b)

In [4]: import copy

In [5]: copy.deepcopy(a) Out[5]: [1, [[...]]] ```

I doubt this is getting hit that much given it requires a recursive data structure, but it does seem like a gnarly error.

Is there some feature that python uses to check whether a data structure is recursive when it's copying, which we're not taking advantage of? I can look more later.

Float indexes are often a source of pain, unfortunately!

...also for my ability to know what's going on, apparently :). Thanks a lot @benbovy .

Yes, that would be great to raise a more informative error. We could also put an issue in upstream if pandas itself has the same issue.

Ah, right. Does it select a value with just nc_bug.sel(lon = 161.001, tolerance=0.1)? Because the lon value which that selects is probably the value you need to use in the slice.

Float indexes are often a source of pain, unfortunately!

Generally this is because the floats aren't exactly the same value — does passing tolerance=0.1 help?

I'm not sure what that has to do with xarray though? Does this give the same result?

import numpy as np import pandas as pd num_dates = np.asarray([0., np.nan]) flat_num_dates = num_dates.ravel() flat_num_dates_ns_int = (flat_num_dates * (int(1e9) * 60 * 60 * 24)).astype(np.int64) flat_num_dates_ns_int array([ 0, 9223372036854775807])

Please could you answer the question on whether pandas tests pass?

We're here helping as volunteers; we can only engage on issues if you reciprocate our good faith. Please could you answer this?

What are the bogus values?

Please could you answer the question on whether pandas tests pass?

It looks lie many of these occur in pandas code — do pandas tests pass?

Agree with (1) or (3). I do (1) a lot, no harm in adding it to xarray.

I could also imagine (2) with options for backends (e.g. pandas as one option). But I would vote against developing our own.

One point aside — when this is done, we may be able to turn on mypy's strict mode, at least for the tests path, so then tests always need annotations, and our annotations get tested.

(for context, a year ago or so we found some of them were wrong, but weren't being tested, because -> None wasn't in the tests)

Thanks @slevang ! Feel free to add a whatsnew, no requirement to though, we'll merge this shortly either way

(if you want to add a whatsnew then great, no problem if not, I'll set it to merge when tests complete)

Thanks a lot @slevang !

Congrats for doing all these!! This must be (almost?) the last of untyped modules?

Nothing wrong with None, it is just pythons default.

The intention of replace_none=False was to leave None as None, which is important for some low level functions as they might be optimized (like numpy sum, which sums over all axes for None).

Not relevant to this PR but for background — it used to be that da.groupby() defaulted to None, and reduced all dimensions — now for a couple of years we require ....

But still da.sum() is equivalent to da.sum(...), which is arguably a bit incongruent with da.sum('a') reducing fewer dimensions than da.sum(['a','b']). But would be quite hard to change now.

I always thought that these two methods are incompatible. But I guess ... Is synonym for None (= all dims) and if ... Appears in an iterable, it just means replace it with all leftover dims.

Yes! ... is the better synonym — None is somewhat an artifact of history. So +1 for replace_none, which maybe we can gradually turn to False by default over time.

Here's the diff from pytest-accept (it is weird that it's slightly different on windows...)

```diff commit 83615a94a6b7c0ae0cf0e0240d7705d9ce6c21e5 Author: Maximilian Roos m@maxroos.com Date: Sat Sep 17 12:36:45 2022 -0700

pytest-accept

diff --git a/xarray/core/_reductions.py b/xarray/core/_reductions.py index a7cf7ec2..d0c2a9d7 100644 --- a/xarray/core/_reductions.py +++ b/xarray/core/_reductions.py @@ -97,7 +97,7 @@ def count( <xarray.Dataset> Dimensions: () Data variables: - da int32 5 + da int64 5 """ return self.reduce( duck_array_ops.count, @@ -4400,7 +4400,7 @@ def count(

     >>> da.groupby("labels").count()
     <xarray.DataArray (labels: 3)>

• array([1, 2, 2], dtype=int64)
• array([1, 2, 2]) Coordinates: * labels (labels) object 'a' 'b' 'c' """ @@ -5485,7 +5485,7 @@ def count(

   >>> da.resample(time="3M").count()
   <xarray.DataArray (time: 3)>
  

  • array([1, 3, 1], dtype=int64)
  • array([1, 3, 1]) Coordinates:
    • time (time) datetime64[ns] 2001-01-31 2001-04-30 2001-07-31 """ ```

I think I really empathize with the pain here. There's a very real explicitness vs "helpfulness" tradeoff, often depending on whether people are doing exploratory research vs hardened production (a bit like Ask vs Guess culture!).

But from the perspective of someone who works with lots of people who use Xarray for their daily research, I think this would be a big hurdle, even without considering the change costs.

One analogy is xarray vs. pandas for 2D data — among my colleagues xarray is known to be a smaller, more reliable API surface, while pandas is more fully featured but also a maze of surprising methods and behavior (df['a'] * df!). Forcing explicit alignment would strengthen that case. But it could take it too far — operations that you expect to just work would now need nannying.

"Make another mode" can seem like an easy decision — "who doesn't want another mode" — but it could make development more difficult, since we'd need calls to check which mode we're in & tests for those. It's not insurmountable though, and maybe it would only be required in a couple of methods, so testing those would be sufficient to ensure the resulting behavior would be correct?

(FWIW we don't use float indexes, so it could be fine to dispense with those)

Excellent @headtr1ck !

Do we need to run pytest --accept to get the docstrings? It looks like we lost lots...

That makes sense. Until mypy make the change, I think this is a nice signpost for users, and will be easily forward compatible…

Thanks a lot @headtr1ck !

Great, thanks @headtr1ck ! And for the typing too

@max-sixty you will probably enjoy this extra automation 🤖

Haha thanks!! Prayers do get answered.

I guess it's imperfect if it's just doing the robotic thing — a formatting PR is going to get a whole lot of labels — ideally the process would understand its weight. But let's definitely give it a go!

Re nearest, does it replicate with exact lookups?

That sounds quite unfriendly!

A couple of questions to reduce the size of the example, without providing any answers yet unfortunately:

• Is process_map from tqdm? Do you get the same behavior from the standard multiprocessing?
• What if we remove method=nearest?
• Is the file a single netCDF file?

Great idea — doing anything that's expensive on repr has caught us a couple of times and can be a frustrating perf issue. Thanks @Illviljan !

Thanks @raybellwaves !

If this is helpful to anyone, here are some configs I use to: a) avoid opening a browser b) avoid pushing to main

This will push the current branch, and tell GH to merge as soon as test pass. I never feel the need to push to main now; even something like the release cleanup can be done through an PR.

pub-merge-gh = !git publish && gh pr create --fill && gh pr merge --auto --squash --delete-branch publish = "!git push --set-upstream origin $(git branch --show-current)"

(the latter can be replaced with push with the latest version of git & [push]; autoSetupRemote = true configs.

The difference is that one has a name of 0:

```python

In [7]: da.sel(x=0) Out[7]: <xarray.DataArray (y: 2)> array([1, 2]) Dimensions without coordinates: y

In [8]: da.to_dataset(dim='x')[0] Out[8]: <xarray.DataArray 0 (y: 2)> array([1, 2]) Dimensions without coordinates: y

In [9]: da.to_dataset(dim='x')[0].name Out[9]: 0

```

This shouldn't prevent the plotting from working — that is indeed a bug....

Sorry, I just read through #6818, mea culpa. It's really unlucky to have a "hole" between releases that pass!

If we've already done the work, then we may as well merge? And then after the next release we can bump the version, such that our latest release for numpy 1.20 works?

Are we still supporting numpy 1.20? If we are, presumably it should be covered in our min-versions CI?

I'll close but please open an bug report if we do see it.

I'm not sure on the exact version — but do we see this in the latest release? https://github.com/pydata/xarray/releases/tag/v2022.03.0

I would say very little. I'm a lazy programmer.

Haha, us both Ray!

I do think that part of laziness is not having to remember too much — so hopefully I can trade you the costs of an extra method call for more consistency!

Resurrecting this, as discussed on the dev call.

Could we replace the pandas decorator with the one from the standard library? That may require adding __dict__ as a slot.

Then as long as the benchmarks still look good, there was consensus that we should merge.

What's the advantage of this over the transpose call?

The transpose approach is more modular, since it takes advantage of the orthogonality of the methods — i.e. we have one method for all usages, rather than kwargs in lots of methods.

We've also managed to have axis as a hidden implentation detail, and this would start exposing it.

Don't put such decisions on a mere mortal!

I would say switch given it sounds like da & ds caused some confusion. Even if personally I was OK with da & ds

Yes, agree they are not imported — good point but I think this would be OK

your suggestion would be to name them dataarray and dataset?

That would be great I think!

I agree with moving them!

But I haven't seen ..._fixture in pytest before, and it makes the names longer — could I ask what the benefit of that is? If we wanted dataarray & dataset then that would be fine...

As discussed on the call: - We'd like to move to .rename and .rename_vars as separate methods on DataArray; the latter renaming coords. - We would "soft-deprecate" .rename for renaming coords — i.e. remove documentation, but not give any warnings, at least for a while. This was a successful approach for .drop. - .rename_vars is a slightly odd name given there are only coords. But it's consistent with xr.Dataset.

After the call, I realize that I didn't mention that Dataset.rename is a synonym for Dataset.rename_vars. Would be also soft deprecate Dataset.rename?

Thank you v much @headtr1ck !

As discussed on the dev call — we can plan to move to dim, with the exception of constructors!

I feel honored thanks! But given that I will become a father any day now, I don't think I will be able to join regularly...

Congrats on the forthcoming arrival!

Ofc, no stress if you can't make the meeting, and obv zero stress if you can't make lots of them.

Is it intentional that DataArrayCoordinates and DatasetCoordinates are not part of api?

Good question, I'm not sure. They are not intended to be created by users IIUC, it's more like a "view" of the underlying coords. Does anyone have a view?