`zarr.Array.__len__` removed in v3 rewrite

[h-mayorquin]

zarr.Array in v2 implemented __len__, returning shape[0] for dimensioned arrays and raising TypeError for 0-dimensional arrays, matching numpy's behavior exactly:

zarr-python/zarr/core.py

Lines 649 to 654 in 3ad97b9

	def __len__(self):
	if self.shape:
	return self.shape[0]
	else:
	# 0-dimensional array, same error message as numpy
	raise TypeError("len() of unsized object")

In zarr v3, __len__ is not defined on Array, so len(array) raises TypeError: object of type 'Array' has no len() for all arrays regardless of dimensionality.

We encountered this while migrating hdmf-zarr to zarr v3 (PR #325). Our code uses hasattr(obj, "__len__") and len() calls to distinguish arrays from scalars, which previously worked consistently across numpy arrays, h5py datasets, and zarr v2 arrays.

I searched the zarr-python issue tracker for any prior discussion of __len__ on Array but could not find something very specific. This change is also not mentioned in the v3 migration guide. I suspect it was dropped to align with the Python array API standard, which does not include __len__ on array objects. My main interest in filing this is so it is documented and discoverable for anyone who runs into it while migrating from v2.

[d-v-b]

Maybe the most related discussion is here: #2529

the basic problem is that __len__ as used by numpy denotes the number of values you get when you iterate over a numpy array, i.e. the length of the first dimension:

>>> len(np.zeros((10,5)))
10
>>> len([x for x in np.zeros((10,5))])
10

For numpy arrays, everything is in memory, so this kind of iteration is cheap. For zarr arrays, everything is probably not in memory, so per-element iteration is potentially extremely expensive. In the worst case, you have to load the entire array into memory.

IMO iterating over a zarr array should not do any IO and should yield spatially-resolved lazy sub-arrays, one per chunk. In that case, the len(array) will tell you the number of chunks. But this requires a major API evolution we have not started yet.

[abishop1990]

I'd like to work on this issue. Here's my analysis:

Array Class Location: src/zarr/core/array.py (lines 282 for AsyncArray, 1950 for Array)

Current Implementation:

• getitem: ✓ exists (line 2683)
• setitem: ✓ exists (line 2836)
• array: ✓ exists (line 2664)
• len: ✗ does NOT exist
• shape property: ✓ delegates to async_array.metadata.shape
• ndim property: ✓ delegates to len(async_array.metadata.shape)

Proposed Implementation:

1. Add len method to AsyncArray class (~line 1045, after shape property)
   • Return self.shape[0] if self.ndim > 0
   • Raise TypeError for 0-dimensional arrays (matching numpy behavior)
2. Add len method to synchronous Array class (~line 2290, after shape property)
   • Delegate to self.async_array.len()
3. Add comprehensive tests in tests/test_array.py
   • Test 1-D array (shape[0])
   • Test 2-D array (shape[0])
   • Test 3-D+ array (shape[0])
   • Test 0-D array raises TypeError
   • Verify error message matches numpy

Test Strategy:

• Unit tests for various array shapes
• Edge case: 0-dimensional arrays
• Verify behavior matches numpy exactly
• Run full test suite to ensure no regressions

Implementation Plan:

1. Implement len in AsyncArray
2. Implement len in Array (synchronous wrapper)
3. Add 5-6 test cases
4. Run pytest locally
5. Code review for quality
6. Submit PR

Ready to proceed with implementation!