print_tree of parent can freeze shape of child

[ddkohler]

e.g.

root = wt.Collection(name="root")
data = root.create_data("data")

root.print_tree()

data.create_variable(name="x", values=np.arange(4))
data.transform("x")

print(data.shape)

data.shape is (). If root.print_tree() is removed, shape is (4,).

Seems to only apply when parent is called. e.g shape remains (4,) if data.print_tree() is called before or after create_variable.

[ksunden]

This is only indirectly due to the print tree call:

The shape is cached when you look it up, so even just a print(data.shape) will do the same.

In most cases it is not a valid operation to change the shape of the data by adding variables... cases where it is valid include:

• First variable/channel added (here); this is the only place where adding ndim (without generating a new data object) is valid, as far as I'm concerned
• adding a broadcasting axis for an existing ndim

We currently do nothing to enforce these constraints.

My proposal is to put these checks into the create_x functions and invalidate the shape cache (self._shape = None) accordingly. This will also help prevent creation of broken data objects with inconsistent shapes.

[darienmorrow]

This flavor of problem---poorly formed data object creation causing wonky downstream issues--- is similar to a problem I had with units. #1010

I am wondering if we should think carefully about what constraints we are assuming, and then explicitly checking those on data object creation.

Explicit is better than implicit.