Cube.coords mesh_coords key [AVD-1662]#4063
Cube.coords mesh_coords key [AVD-1662]#4063bjlittle merged 2 commits intoSciTools:mesh-data-modelfrom
Conversation
| # But put these *afterward*, unlike other similar classes. | ||
| for item in ("standard_name", "units", "long_name", "attributes"): | ||
| for item in ( | ||
| "shape", |
There was a problem hiding this comment.
@pp-mo Snuck in shape here... no objections, just curious as to the reasoning
There was a problem hiding this comment.
Well it seems clear that when printing these mesh information components, we don't want to realise or print out contents.
But when debugging I saw the printouts, it seemed odd you couldn't even see the shape., unlike dask arrays which show the shape + dtype.
So I added it in (but not dtype).
Since then I realised that you + @trexfeathers had already agreed a printout format for Connectivity, which does not include shape.
So I now think that we should probably at least make those 2 the same :
What do you think + which way do you reckon we should we jump ?
There was a problem hiding this comment.
@pp-mo Awesome, thanks.
I was going to re-haul how coordinates in general do __str__ and __repr__ in order to keep everything lazy.
I think there is real tangible benefit there, but outside the scope of this PR
2 participants
🚀 Pull Request
Description
Adding a 'mesh_coords' keyword to Cube.coords.
Behaves mostly like the existing
dim_coordskeyword.(This is a simple preliminary to adding the more complex cube api to come :
cube.meshand.locationcube.__eq__should compare mesh and location)
Consult Iris pull request check list