DataTree.children repr is inconsistent with DataTree.parent (rich HTML vs. flat nested text)

[ericmjl]

What I expected

.parent and .children are symmetric tree-navigation operations — one step up, one step down. I expected them to render with parallel visual treatment.

What I got

They're rendered completely differently.

.parent returns a DataTree and gets the beautiful collapsible HTML repr:

>>> precipitation["reanalysis"].parent
<xarray.DataTree>
Group: /
├── Group: /observed
└── Group: /reanalysis
    ... (collapsible, indented, color-coded)

.children returns a Frozen mapping of name → DataTree, and each child's full repr is inlined as flat nested text:

>>> precipitation.children
Frozen({'observed': <xarray.DataTree 'observed'>
Group: /observed
    Dimensions:        (time: 10, lon: 320, lat: 150)
    Coordinates: ...
    Inherited coordinates: ...
    Data variables: ...
    ..., 'reanalysis': <xarray.DataTree 'reanalysis'>
Group: /reanalysis
    Dimensions: ...
    ...})

Two problems compound:

1. Inconsistency. .parent (up) gives a structural view; .children (down) gives a flat dict. The asymmetry makes the API feel cobbled together.
2. The tree shape is invisible at the exact moment you need it. .children is the operation that asks "what's below me?" — and the answer comes back as a wall of inline text with no hierarchy.

Why it matters

I was working through the DataTree tutorial at SciPy 2026, and the contrast jumped out immediately. The DataTree's HTML repr is excellent — it carries the whole "this is a hierarchy" mental model on its own. Then .children breaks that thread, dumping a verbose nested dict that obscures exactly the structure you're asking about.

For someone learning the API, the name .children promises a structural view. The repr delivers a wall of text.

Concrete proposal

My preferred direction is option 1, if maintainers are open to it:

1. Preferred — reuse the existing DataTree HTML repr machinery. .children renders as a forest of mini-trees, each child shown with the same collapsible, indented treatment a standalone DataTree gets. Click-to-expand handles the verbosity, and the visual language matches .parent exactly. The repr code already exists; this is mostly a question of invoking it per-child and wrapping the results.

   Fallbacks if the full version is too much:

2. Medium: A collapsible HTML view where each child expands into its full DataTree repr inline, collapsed by default. Less reuse of existing machinery, but still gives hierarchy + scannability.

3. Minimum viable: An indented bulleted list of child names with a one-line summary each (path, dims, variable count). Skip the full per-child DataTree repr — that's what selecting the child is for. Easiest to land, closes most of the gap with .parent.

Environment

• xarray version: 2026.7.0
• Discovered while working through fundamentals/01_datatree_hierarchical_data.ipynb at SciPy 2026

[ericmjl]

(Also, I am more than happy to help with contributing the code if need be, as long as there's capacity for review!)

[keewis]

Contributions welcome! I think the main problem to solve would be how to visualize the forest of subtrees. Once that's done we'd have to replace the return type (Frozen wrapping a dict) with a custom dict-like type that overrides _repr_html_.