RFC: new coordinate print output

[pp-mo]

Please see #4499 for initial code (hacky but you can test it) and sample outputs.

This new format actually applies (or will do) to all _DimensionalMetadata,
So it should also replace the special-case code currently provided in MeshCoord.

With this in hand, we can then easily make a nicer printout for Mesh, too.

[wjbenfold]

Generally love how these look, it's really tight, informative and covers every case I can think of.

Most minor of suggestions - could label the points and bounds consistently with the other attributes (e.g. points: [... and bounds: [) as I sometimes forget a coord has points not data and so presumably so do some users sometimes too (and would print something I don't know how to interrogate as a first step to checking what I'm doing). That would also mean bounds don't end up indented differently to points.

[pp-mo]

Thanks for this.
I have tried it out, so you now get, e.g.

SCALAR:
------------REPR:-------
<AuxCoord: forecast_period / (hours)  [15.]>
------------STR:--------
AuxCoord :  forecast_period / (hours)
    points: [15.]
    shape: (1,)
    dtype: float64
    standard_name: 'forecast_period'
------------------------


==== REAL DATA nc test cube coords ...
------------REPR:-------
<DimCoord: time / (days since 1850-01-01)  shape=(4,)>
------------STR:--------
DimCoord :  time / (days since 1850-01-01)
    points: [
        2046-01-01 12:00:00, 2046-01-02 12:00:00,
        2046-01-03 12:00:00, 2046-01-04 12:00:00]
    bounds: [
        [2046-01-01 00:00:00, 2046-01-02 00:00:00],
        [2046-01-02 00:00:00, 2046-01-03 00:00:00],
        [2046-01-03 00:00:00, 2046-01-04 00:00:00],
        [2046-01-04 00:00:00, 2046-01-05 00:00:00]]
    shape: (4,) ; bounds=(4, 2)
    dtype: float64
    standard_name: 'time'
    long_name: 'time'
    var_name: 'time'

What do people think ?

[lbdreyer]

I do like the labelling of

points: [...
bounds: [...
shape:
...

looks neater and I like the consistency of the : as opposed to a mismatch of it sometimes being =
Also it might be nicer for new users to interpret the printout if we explicitly say they are points, rather than assume the user will know that

Although it may be a bit more of pain to implement when it comes to the different _DimensionMetadata (ancilliary variables, cell measures, etc) since the terms for the values differ across these!

[wjbenfold]

Although it may be a bit more of pain to implement when it comes to the different _DimensionMetadata (ancilliary variables, cell measures, etc) since the terms for the values differ across these!

I think the varying of terms adds weight to including the name so that users can find it out :)

[pp-mo]

varying of terms

Well I have arranged that, but in a way that maybe it's a wee bit ugly...

iris/lib/iris/coords.py

Lines 60 to 62 in 4e1867d

	# Used by printout methods : __str__ and __repr__
	# Overridden in subclasses : Coord->'points', Connectivity->'indices'
	_values_array_name = "data"

iris/lib/iris/coords.py

Lines 1456 to 1462 in 4e1867d

	class Coord(_DimensionalMetadata):
	"""
	Abstract base class for coordinates.
	"""
	_values_array_name = "points"

[pp-mo]

While I was at the previous, I also thought to replace "<lazy>" with actual dask array printouts (in the long-form).
Giving things like ..

Small co with lazy points
dask.array<array, shape=(4,), dtype=float32, chunksize=(4,), chunktype=numpy.ndarray>
------------REPR:-------
<AuxCoord: latitude / (degrees)  <lazy>, shape=(4,)>
------------STR:--------
AuxCoord :  latitude / (degrees)
    points: dask.array<array, shape=(4,), dtype=float32, chunksize=(4,), chunktype=numpy.ndarray>
    shape: (4,)
    dtype: float32
    standard_name: 'latitude'
------------------------


Small co with real points but lazy bounds
------------REPR:-------
<AuxCoord: latitude / (degrees)  <lazy>, shape=(4,)>
------------STR:--------
AuxCoord :  latitude / (degrees)
    points: [89.999985 87.499985 84.999985 82.499985]
    bounds: dask.array<array, shape=(4, 2), dtype=float32, chunksize=(4, 2), chunktype=numpy.ndarray>
    shape: (4,) ; bounds=(4, 2)
    dtype: float32
    standard_name: 'latitude'
------------------------

How does that seem?

[rcomer]

This gives me

AuxCoord :  time / (hours since 1970-01-01 00:00:00)
    points: dask.array<copy, shape=(72,), dtype=float64, chunksize=(72,), chunktype=numpy.ndarray>
    bounds: dask.array<copy, shape=(72, 2), dtype=float64, chunksize=(72, 2), chunktype=numpy.ndarray>
    shape: (72,) ; bounds=(72, 2)
    dtype: float64
    standard_name: 'time'
    var_name: 'time'

I think I prefer it without, as it's more compact. The shape and dtype information is duplicated here and I've never thought to wonder what sort of chunks my coordinates have. I don't know what the "copy" bit even means!

[pp-mo]

Just for note: I'm still making some changes here for specific things...
Hoping to add some tests + un-draft the PR #4499 by tomorrow

(1.) date-units calendar
I decided that whereas the existing printout treats 'calendar' as if it were a Coord property, IMHO it makes far more sense to show this with the unit, where it belongs. So, following a discussion with @trexfeathers regarding sensible formatting, I'm currently outputting header lines like

DimCoord :  time / (days since 2015-05-17, gregorian calendar)

In a way, it would be "better" if cf_units.Unit.__str__ itself did this, but we can perhaps see why it does not, preferring to keep the calendar attribute as a separate item from the text content.
For consistency's sake, however, I think it makes sense for Iris to also do this for Iris Cubes with date units (though that is a pretty rare case). Especially since the new Coord printout format is based on that anyway. I think I can make that changes, without much fanfare, on the grounds that it is a really rarely occurence.

(2.) lazy arrays
reverted to printing <lazy>, instead of the dask representation, since that is so noisy -- as @rcomer suggestion

(3.) too-long arrays in repr
a) where an array printout is overlong to fit a repr string, now prints

<type:  name / (units)   [...]  shape(N,)>

rather than just

<type:  name / (units)  shape=(N,)>

-- i.e. we use [...] as a placeholder for an array we can't print (much like <lazy>).

b) - in similar cases where a summary with ellipsis won't fit, but a single point can, it will now print [<first>, ...]
-- this is more useful for dates, especially

(4.) bounds shape
the with-bounds form of the shape line is now, e.g. like

shape: (10,)  bounds(10, 2)

[pp-mo]

Okay I just thought of something else...
To be properly consistent with the Cube printout, we should really be aligning the columns.
Like this, for example :

height / (degree s-1)               (x: 2)
    Dimension coordinates:
        x                             x
    Auxiliary coordinates:
        additional                    x
    Scalar coordinates:
        qqq                         string
    Attributes:
        a                           1
        b                           6.3

So, versions of some of the above Coord printouts, compared with/without column alignment, might look like this ...

AuxCoord :  forecast_period / (hours)
    points: [15.]
    shape: (1,)
    dtype: float64
    standard_name: 'forecast_period'
---
AuxCoord : forecast_period / (hours)
    points         [15.]
    shape          (1,)
    dtype          float64
    standard_name  'forecast_period'

AuxCoord :  latitude / (degrees)
    points: [89.999985 87.499985 84.999985 82.499985]
    bounds: <lazy>
    shape: (4,) ; bounds=(4, 2)
    dtype: float32
    standard_name: 'latitude'
----
AuxCoord :  latitude / (degrees)
    points:        [89.999985 87.499985 84.999985 82.499985]
    bounds:        <lazy>
    shape:         (4,) ; bounds=(4, 2)
    dtype:         float32
    standard_name: 'latitude'

DimCoord :  time / (days since 1850-01-01, gregorian calendar)
    points: [
        2046-01-01 12:00:00, 2046-01-02 12:00:00,
        2046-01-03 12:00:00, 2046-01-04 12:00:00]
    bounds: [
        [2046-01-01 00:00:00, 2046-01-02 00:00:00],
        [2046-01-02 00:00:00, 2046-01-03 00:00:00],
        [2046-01-03 00:00:00, 2046-01-04 00:00:00],
        [2046-01-04 00:00:00, 2046-01-05 00:00:00]]
    shape: (4,)  bounds(4, 2)
    dtype: float64
    standard_name: 'time'
    long_name: 'time'
    var_name: 'time'
---
DimCoord :  time / (days since 1850-01-01, gregorian calendar)
           points  [
              2046-01-01 12:00:00, 2046-01-02 12:00:00,
              2046-01-03 12:00:00, 2046-01-04 12:00:00]
           bounds  [
              [2046-01-01 00:00:00, 2046-01-02 00:00:00],
              [2046-01-02 00:00:00, 2046-01-03 00:00:00],
              [2046-01-03 00:00:00, 2046-01-04 00:00:00],
              [2046-01-04 00:00:00, 2046-01-05 00:00:00]]
            shape  (4,)  bounds(4, 2)
            dtype  float64
    standard_name  'time'
    long_name      'time'
    var_name       'time'

Looking at those, I suppose it is more consistent with Cube printouts,
but I can't convince myself that this is actually helpful.

Does anyone have strong feelings about this ?

[lbdreyer]

Personally not a fan of column alignment. It makes sense for the cube because that includes diagram showing which dimensions the coord maps to. If it weren't for that, I would say to drop the column alignment.

The trouble with the column alignment is that it is hugely dependent on the length of the coordinate names (in the case of the cubes) and the coord properties (in the case of the coords). If we were to have a case of adding a new property with a particularly long name (as we were considering with `bounds_are_climatological, this could cause the columns to be very stretched out

AuxCoord : time / (days since 1850-01-01, gregorian calendar)
    points:                               <lazy>
    bounds:                               <lazy>
    shape:                                (40,)  bounds(40, 2)
    dtype:                                float64
    standard_name:                        'time'
    long_name:                            'time'
    var_name:                             'time'
    a_property_with_a_very_very_long_name: True

[pp-mo]

Thanks @lbdreyer I'm inclined to agree. Basically, when we re-vamped the Cube str output, I thought we were going to re-use that facility here. But now I've tried it, I don't think it is a good solution for the Coords.

[trexfeathers]

I also want to re-iterate something I said to @pp-mo yesterday: you've already added 95% of the value; if there's something big/contentious it might be better to merge without and raise a new issue 🙂

[wjbenfold]

I'm happy without the alignment, and I agree with @trexfeathers that this is already a huge improvement and we could spend ages on the details without adding much extra (if that was indeed his point)

[lbdreyer]

Looking much better! I've always found coords quite hard to read so this is a big improvement. Below are the comments I noted down as I was reading through the examples (I can split these into multiple posts if you would prefer!)

Small co with real points but lazy bounds

I'm confused by this one. You say the points are real but then they are displayed as <lazy> in the repr

Small co with real points but lazy bounds
------------REPR:-------
<AuxCoord: latitude / (degrees)  <lazy>, shape=(4,)>
------------STR:--------
AuxCoord :  latitude / (degrees)
    <lazy>
    shape: (4,) ; bounds=(4, 2)
    dtype: float32
    standard_name: 'latitude'
------------------------

Is this just a mistake, or intentional?

repr inconsistencies

There seem to be some inconsistencies as to what is included in the repr, in particular whether the points and/or shape are displayed. My interpretation of what going on is that

• if the points array is small, you display the points and no shape
• if the points array is large, you display the start and end of the points, as well as the shape (to hint there is more not being displayed)
• if the points are datetimes, you just display the shape

This may be confusing to a user if they are not familiar with what to expect. Say a user pretty much never handles time coordinates but then one day they have a time coordinate, if they look at the repr they will be confused as to where the points went.
Three proposals:

1. Add something like <points> or <numpy.array> <dask.array> where points would live in a time coord: <DimCoord: time / (days since 1850-01-01) <points> shape=(4,)> so similar to what you do with a lazy array. But maybe this is ugly?
2. Always include the shape, even for small coords<DimCoord: temp / (K) [0, 1, 2, 3] shape=(4,)> to avoid a user being confused by the fact that the shape is sometimes included and sometimes not
3. Never show the points, even for small integer coords <DimCoord: temp / (K) shape=(4,)>this would be consistent at least!
   My major source of concern is that if you weren't familiar withe rules listed above in my bullet points, would it be confusing! I suppose it also depends on what the intention behind repr is, which brings me to the next point:

repr terseness

I'm not so sure about using the repr in this way. Python docs for repr say that

the “official” string representation of an object. If at all possible, this should look like a valid Python expression that could be used to recreate an object with the same value ... This is typically used for debugging, so it is important that the representation is information-rich and unambiguous.

And then the __str__ is the informal string.
Did you have a particular scenario in mind for when a shortened version of __repr__ would be helpful?

attributes

It's nice that things are spaced out, on their own lines, but this may get a bit messed up by attributes. What if the attributes dict was particularly long? We could display them similar to a cube does where they each have their own line

DimCoord :  height / (m)
    [10.]
    shape: (1,)
    dtype: float64
    standard_name: 'height'
    long_name: 'height'
    var_name: 'height'
    attributes: 
       positive: up

[pp-mo]

@lbdreyer repr terseness

Did you have a particular scenario in mind for when a shortened version of repr would be helpful?

It's entirely designed for use at the command line, where a command result prints as repr.
It is non-standard, but this is exactly what we have for Cube, and I think it does work.
E.G.

>>> cube = load(...)
>>> cube
<iris 'Cube' of height / (degree s-1) (x: 2)>
>>> print(cube)
height / (degree s-1)               (x: 2)
    Dimension coordinates:
        x                             x
    Auxiliary coordinates:
        additional                    x
    Scalar coordinates:
        qqq                         string
>>> cube.coord('x')
<DimCoord: x / (unknown)  [0, 1]>
>>> print(cube.coord('x'))
DimCoord :  x / (unknown)
    points: [0, 1]
    shape: (2,)
    dtype: int64
    long_name: 'x'
>>> 

[wjbenfold]

When I print a list of cubes (not a cubeList) I get the repr of each one - would that also happen for coords when they have a repr? Currently printing a list of coords prints a lot of arrays.

[rcomer]

When I print a list of cubes (not a cubeList) I get the repr of each one - would that also happen for coords when they have a repr? Currently printing a list of coords prints a lot of arrays.

In [3]: print(cube.coords())
[<DimCoord: realization / (1)  [1, 2, ..., 6, 7]  shape(7,)>, <DimCoord: forecast_reference_time / (hours since 1970-01-01 00:00:00)  [...]+bnds  shape(72,)>, <DimCoord: longitude / (degrees)  [180.]+bnds>, <AuxCoord: season / (no_unit)  [djf|djf|djf]>, <AuxCoord: forecast_period / (hours)  <lazy>  shape(72,)>, <AuxCoord: season_year / (1)  <lazy>  shape(72,)>, <AuxCoord: time / (hours since 1970-01-01 00:00:00)  <lazy>  shape(72,)>]

[pp-mo]

When I print a list of cubes (not a cubeList) I get the repr of each one - would that also happen for coords when they have a repr? Currently printing a list of coords prints a lot of arrays.

As @rcomer shows, it will be better. But not as neat as a list of cubes, because we make that print in a special way, whish lists each on a single line against the numeric indicies.
However this isn't delivered simply by printing a list of cubes, but in fact a CubeList (such as iris.load returns).

>>> cubes = [Cube(0, long_name=f'c{i}') for i in range(3)]
>>> print(cubes)
[<iris 'Cube' of c0 / (unknown) (scalar cube)>, <iris 'Cube' of c1 / (unknown) (scalar cube)>, <iris 'Cube' of c2 / (unknown) (scalar cube)>]
>>> print(CubeList(cubes))
0: c0 / (unknown)                      (scalar cube)
1: c1 / (unknown)                      (scalar cube)
2: c2 / (unknown)                      (scalar cube)
>>> 

I have personally argued that the printout is about the only good purpose of a CubeList !
I don't really think creating a "CoordList" is worth it.

[pp-mo]

@lbdreyer Small co with real points but lazy bounds

This was a under previous implementation, which I think was bugged.
I am now showing "<lazy>" in the repr output for either points or bounds -- but only the points in the repr form, as I judged that bounds won't fit well in the on-line format.

[pp-mo]

@lbdreyer repr inconsistencies

...
if the points array is small, you display the points and no shape
if the points array is large, you display the start and end of the points, as well as the shape (to hint there is more not being displayed)
if the points are datetimes, you just display the shape

This may be confusing to a user if they are not familiar with what to expect. Say a user pretty much never handles time coordinates but then one day they have a time coordinate, if they look at the repr they will be confused as to where the points went.

Again, I have improved this somewhat, since the original examples.
I already adopted the suggestion to always show something where the array goes.
There are now 3 different forms ...

• full values, e.g. [1, 2, 3]
• partial values with an ellipsis e.g. [1.1, 2.0, ... , 7.4, 9.333]

(N.B. these first 2 are entirely down to numpy, and can be adjusted with printoptions, e.g. precision + max_width).

• a single value with an ellipsis, e.g. [2021-01-17 13:15:00, ...].
  I added this form specifically for dates
• a placeholder [...] -- when even a single value is too wide (e.g. a long string).

The choice between style is (and always was) entirely determined by the printing width : I simply output the longest form that will fit.

Meanwhile, the shape is currently only shown when we didn't print all the values. Which was mainly to make the scalar coords easier to look at.
But I agree, it is possibly confusing, and I could reasonably always print the shape
-- or maybe only omit it to for scalar coords.
I think I like that best + I have adopted that for now.
Does anybody think differently ?

[pp-mo]

Unfortunately, it looks like printing examples was basically a bad idea, since the originals are no longer up-to-date, but changing them will confuse the recorded comments + discussion !

I think my best approach is probably to include the latest versions instead.
As-at this commit
[NOTE: updated again later! removed calendar from oneline date units]
Here :

Small section of latitude coord[:2]
------------REPR:-------
<DimCoord: latitude / (degrees)  [90. , 87.5]  shape(2,)>
------------STR:--------
DimCoord :  latitude / (degrees)
    points: [89.999985, 87.499985]
    shape: (2,)
    dtype: float32
    standard_name: 'latitude'
    coord_system: GeogCS(6371229.0)
------------------------

co[:2] with 4x bounds + printoptions(precision=3) 
------------REPR:-------
<DimCoord: latitude / (degrees)  [90. , 87.5]  shape(2,)>
------------STR:--------
DimCoord :  latitude / (degrees)
    points: [90. , 87.5]
    bounds: [
        [90.  , 88.75, 90.  , 88.75],
        [88.75, 86.25, 88.75, 86.25]]
    shape: (2,)  bounds(2, 4)
    dtype: float32
    standard_name: 'latitude'
    coord_system: GeogCS(6371229.0)
------------------------


Longer section co[:5]
------------REPR:-------
<DimCoord: latitude / (degrees)  [90. , 87.5, 85. , 82.5, 80. ]  shape(5,)>
------------STR:--------
DimCoord :  latitude / (degrees)
    points: [89.999985, 87.499985, 84.999985, 82.499985, 79.99999 ]
    shape: (5,)
    dtype: float32
    standard_name: 'latitude'
    coord_system: GeogCS(6371229.0)
------------------------


Longer section co[:5] with bounds
------------REPR:-------
<DimCoord: latitude / (degrees)  [90. , 87.5, 85. , 82.5, 80. ]  shape(5,)>
------------STR:--------
DimCoord :  latitude / (degrees)
    points: [89.999985, 87.499985, 84.999985, 82.499985, 79.99999 ]
    bounds: [
        [90.      , 88.749985],
        [88.749985, 86.249985],
        [86.249985, 83.749985],
        [83.749985, 81.249985],
        [81.249985, 78.74999 ]]
    shape: (5,)  bounds(5, 2)
    dtype: float32
    standard_name: 'latitude'
    coord_system: GeogCS(6371229.0)
------------------------


Short co[:1] -->  one-line bounds
------------REPR:-------
<DimCoord: latitude / (degrees)  [90.]>
------------STR:--------
DimCoord :  latitude / (degrees)
    points: [89.999985]
    bounds: [[90.      , 88.749985]]
    shape: (1,)  bounds(1, 2)
    dtype: float32
    standard_name: 'latitude'
    coord_system: GeogCS(6371229.0)
------------------------


Still longer co[-15:] with bounds
------------REPR:-------
<DimCoord: latitude / (degrees)  [-55. , -57.5, ..., -87.5, -90. ]  shape(15,)>
------------STR:--------
DimCoord :  latitude / (degrees)
    points: [
        -54.99994, -57.49994, -59.99994, -62.49994, -64.99994,
        -67.49994, -69.99994, -72.49994, -74.99994, -77.49994,
        -79.99994, -82.49994, -84.99994, -87.49992, -89.99992]
    bounds: [
        [-53.749947, -56.24994 ],
        [-56.24994 , -58.74994 ],
        ...,
        [-86.24993 , -88.74992 ],
        [-88.74992 , -90.      ]]
    shape: (15,)  bounds(15, 2)
    dtype: float32
    standard_name: 'latitude'
    coord_system: GeogCS(6371229.0)
------------------------


Full co
------------REPR:-------
<DimCoord: latitude / (degrees)  [ 90. , 87.5, ..., -87.5, -90. ]  shape(73,)>
------------STR:--------
DimCoord :  latitude / (degrees)
    points: [ 89.999985,  87.499985, ..., -87.49992 , -89.99992 ]
    shape: (73,)
    dtype: float32
    standard_name: 'latitude'
    coord_system: GeogCS(6371229.0)
------------------------


Full co with bounds
------------REPR:-------
<DimCoord: latitude / (degrees)  [ 90. , 87.5, ..., -87.5, -90. ]  shape(73,)>
------------STR:--------
DimCoord :  latitude / (degrees)
    points: [ 89.999985,  87.499985, ..., -87.49992 , -89.99992 ]
    bounds: [
        [ 90.      ,  88.749985],
        [ 88.749985,  86.249985],
        ...,
        [-86.24993 , -88.74992 ],
        [-88.74992 , -90.      ]]
    shape: (73,)  bounds(73, 2)
    dtype: float32
    standard_name: 'latitude'
    coord_system: GeogCS(6371229.0)
------------------------


Small co with lazy points
dask.array<array, shape=(4,), dtype=float32, chunksize=(4,), chunktype=numpy.ndarray>
------------REPR:-------
<AuxCoord: latitude / (degrees)  <lazy>  shape(4,)>
------------STR:--------
AuxCoord :  latitude / (degrees)
    points: <lazy>
    shape: (4,)
    dtype: float32
    standard_name: 'latitude'
    coord_system: GeogCS(6371229.0)
------------------------


Small co with real points but lazy bounds
------------REPR:-------
<AuxCoord: latitude / (degrees)  [90. , 87.5, 85. , 82.5]  shape(4,)>
------------STR:--------
AuxCoord :  latitude / (degrees)
    points: [89.999985, 87.499985, 84.999985, 82.499985]
    bounds: <lazy>
    shape: (4,)  bounds(4, 2)
    dtype: float32
    standard_name: 'latitude'
    coord_system: GeogCS(6371229.0)
------------------------


Float with masked points
------------REPR:-------
<AuxCoord: latitude / (degrees)  [89.999985, -- , ..., 69.99999 , 67.5 ]  shape(10,)>
------------STR:--------
AuxCoord :  latitude / (degrees)
    points: [
        89.999985, --       , 84.999985, --       , 79.99999 ,
        77.49999 , 74.99999 , 72.49999 , 69.99999 , 67.5     ]
    shape: (10,)
    dtype: float32
    standard_name: 'latitude'
    coord_system: GeogCS(6371229.0)
------------------------


Integer
------------REPR:-------
<AuxCoord: integer_points / (unknown)  [0, 1, 2, 3, 4]  shape(5,)>
------------STR:--------
AuxCoord :  integer_points / (unknown)
    points: [0, 1, 2, 3, 4]
    shape: (5,)
    dtype: int64
    long_name: 'integer_points'
------------------------


Integer with masked points
------------REPR:-------
<AuxCoord: integer_points / (unknown)  [0 , --, 2 , --, 4 ]  shape(5,)>
------------STR:--------
AuxCoord :  integer_points / (unknown)
    points: [0 , --, 2 , --, 4 ]
    shape: (5,)
    dtype: int64
    long_name: 'integer_points'
------------------------


Longer integers with masked points
------------REPR:-------
<AuxCoord: integer_points / (unknown)  [995 , -- , ..., 1018, 1019]  shape(25,)>
------------STR:--------
AuxCoord :  integer_points / (unknown)
    points: [995 , --  , ..., 1018, 1019]
    shape: (25,)
    dtype: int64
    long_name: 'integer_points'
    var_name: 'qq'
------------------------


dates with bounds
------------REPR:-------
<AuxCoord: x / (days since 2015-05-17)  [2015-05-17 00:00:00, ...]  shape(10,)>
------------STR:--------
AuxCoord :  x / (days since 2015-05-17, gregorian calendar)
    points: [
        2015-05-17 00:00:00, 2015-05-28 02:40:00,
        2015-06-08 05:20:00, 2015-06-19 08:00:00,
        2015-06-30 10:40:00, 2015-07-11 13:20:00,
        2015-07-22 16:00:00, 2015-08-02 18:40:00,
        2015-08-13 21:20:00, 2015-08-25 00:00:00]
    bounds: [
        [2015-05-11 10:40:00, 2015-05-22 13:20:00],
        [2015-05-22 13:20:00, 2015-06-02 16:00:00],
        ...,
        [2015-08-08 08:00:00, 2015-08-19 10:40:00],
        [2015-08-19 10:40:00, 2015-08-30 13:20:00]]
    shape: (10,)  bounds(10, 2)
    dtype: float64
    var_name: 'x'
    attributes: {'a': 14, 'b': None}
------------------------


dates with bounds AS DIMCOORD
------------REPR:-------
<DimCoord: time / (days since 2015-05-17)  [2015-05-17 00:00:00, ...]  shape(10,)>
------------STR:--------
DimCoord :  time / (days since 2015-05-17, gregorian calendar)
    points: [
        2015-05-17 00:00:00, 2015-05-28 02:40:00,
        2015-06-08 05:20:00, 2015-06-19 08:00:00,
        2015-06-30 10:40:00, 2015-07-11 13:20:00,
        2015-07-22 16:00:00, 2015-08-02 18:40:00,
        2015-08-13 21:20:00, 2015-08-25 00:00:00]
    bounds: [
        [2015-05-11 10:40:00, 2015-05-22 13:20:00],
        [2015-05-22 13:20:00, 2015-06-02 16:00:00],
        ...,
        [2015-08-08 08:00:00, 2015-08-19 10:40:00],
        [2015-08-19 10:40:00, 2015-08-30 13:20:00]]
    shape: (10,)  bounds(10, 2)
    dtype: float64
    standard_name: 'time'
    var_name: 'x'
    attributes: {'a': 14, 'b': None}
------------------------


dates with masked points
------------REPR:-------
<AuxCoord: x / (days since 2015-05-17)  [2015-05-17 00:00:00, ...]  shape(10,)>
------------STR:--------
AuxCoord :  x / (days since 2015-05-17, gregorian calendar)
    points: [
        2015-05-17 00:00:00, 2015-05-28 02:40:00,
        --                 , 2015-06-19 08:00:00,
        2015-06-30 10:40:00, --                 ,
        2015-07-22 16:00:00, 2015-08-02 18:40:00,
        2015-08-13 21:20:00, 2015-08-25 00:00:00]
    shape: (10,)
    dtype: float64
    var_name: 'x'
    attributes: {'a': 14, 'b': None}
------------------------


single date (nonscalar)
------------REPR:-------
<AuxCoord: x / (days since 2015-05-17)  [2015-06-08 05:20:00]>
------------STR:--------
AuxCoord :  x / (days since 2015-05-17, gregorian calendar)
    points: [2015-06-08 05:20:00]
    shape: (1,)
    dtype: float64
    var_name: 'x'
    attributes: {'a': 14, 'b': None}
------------------------


single date (scalar)
------------REPR:-------
<AuxCoord: x / (days since 2015-05-17)  [2015-06-08 05:20:00]>
------------STR:--------
AuxCoord :  x / (days since 2015-05-17, gregorian calendar)
    points: [2015-06-08 05:20:00]
    shape: (1,)
    dtype: float64
    var_name: 'x'
    attributes: {'a': 14, 'b': None}
------------------------


two dates
------------REPR:-------
<AuxCoord: x / (days since 2015-05-17)  [2015-06-08 05:20:00, 2015-06-19 08:00:00]  shape(2,)>
------------STR:--------
AuxCoord :  x / (days since 2015-05-17, gregorian calendar)
    points: [2015-06-08 05:20:00, 2015-06-19 08:00:00]
    shape: (2,)
    dtype: float64
    var_name: 'x'
    attributes: {'a': 14, 'b': None}
------------------------


multidimensional
------------REPR:-------
<AuxCoord: unknown / (unknown)  [...]  shape(7, 5, 4)>
------------STR:--------
AuxCoord :  unknown / (unknown)
    points: [
        [[1.45665556e+01, 3.96351011e+01, 1.26702547e+00,
          7.18307911e+01],
         [1.84552452e+00, 1.40266380e+00, 4.05984175e+00,
          1.56114764e+00],
         ...,
         [6.93393457e-02, 9.16979225e-02, 1.54235977e+02,
          1.91021665e-01],
         [6.10864186e-01, 4.60077062e+01, 8.73438328e-02,
          3.85486830e-01]],
       
        [[2.92653102e+02, 1.93728482e+02, 2.42184451e+01,
          8.72877404e-01],
         [3.06857983e+00, 9.73565096e+01, 1.05249520e+01,
          1.04612402e+02],
         ...,
         [4.61566030e+00, 6.04202880e+00, 2.81800655e+02,
          5.79813978e+00],
         [6.49159881e+01, 1.02368393e+02, 6.67916950e-01,
          2.46519054e-01]],
       
        ...,
       
        [[2.19291123e+02, 5.65976335e-02, 9.29499263e+00,
          1.21422011e+00],
         [2.45221051e-01, 1.14610881e-01, 1.71235139e+00,
          2.85723484e+00],
         ...,
         [8.21836457e-02, 3.21365389e-01, 9.34131544e-01,
          1.62954679e+00],
         [3.53035232e+02, 1.01540250e+01, 1.08760053e-01,
          1.09878369e+02]],
       
        [[7.38505698e-01, 6.53107941e+00, 7.07119182e-01,
          3.49174184e+01],
         [5.67725754e+01, 3.25509798e+01, 2.23949452e+02,
          2.56721538e+02],
         ...,
         [1.55004240e-01, 7.16895510e+00, 2.52594680e+00,
          7.08283953e-02],
         [2.30093079e+01, 2.70825765e-01, 7.09837521e-02,
          2.32071599e+02]]]
    shape: (7, 5, 4)
    dtype: float64
------------------------


small multidim
------------REPR:-------
<AuxCoord: unknown / (unknown)  [[14.567, 39.635], [ 1.846, 1.403]]  shape(2, 2)>
------------STR:--------
AuxCoord :  unknown / (unknown)
    points: [
        [14.56655564, 39.63510108],
        [ 1.84552452,  1.4026638 ]]
    shape: (2, 2)
    dtype: float64
------------------------


SCALAR:
------------REPR:-------
<AuxCoord: forecast_period / (hours)  [15.]>
------------STR:--------
AuxCoord :  forecast_period / (hours)
    points: [15.]
    shape: (1,)
    dtype: float64
    standard_name: 'forecast_period'
------------------------


==== REAL DATA nc test cube coords ...
------------REPR:-------
<DimCoord: time / (days since 1850-01-01)  [2046-01-01 12:00:00, ...]  shape(4,)>
------------STR:--------
DimCoord :  time / (days since 1850-01-01, gregorian calendar)
    points: [
        2046-01-01 12:00:00, 2046-01-02 12:00:00,
        2046-01-03 12:00:00, 2046-01-04 12:00:00]
    bounds: [
        [2046-01-01 00:00:00, 2046-01-02 00:00:00],
        [2046-01-02 00:00:00, 2046-01-03 00:00:00],
        [2046-01-03 00:00:00, 2046-01-04 00:00:00],
        [2046-01-04 00:00:00, 2046-01-05 00:00:00]]
    shape: (4,)  bounds(4, 2)
    dtype: float64
    standard_name: 'time'
    long_name: 'time'
    var_name: 'time'
------------------------

------------REPR:-------
<DimCoord: latitude / (degrees)  [-89.142, -88.029, ..., 88.029, 89.142]  shape(160,)>
------------STR:--------
DimCoord :  latitude / (degrees)
    points: [
        -89.14151943, -88.02942887, ...,  88.02942887,
         89.14151943]
    bounds: [
        [-90.        , -88.62472856],
        [-88.62472856, -87.49119059],
        ...,
        [ 87.49119059,  88.62472856],
        [ 88.62472856,  90.        ]]
    shape: (160,)  bounds(160, 2)
    dtype: float64
    standard_name: 'latitude'
    long_name: 'latitude'
    var_name: 'lat'
------------------------

------------REPR:-------
<DimCoord: longitude / (degrees)  [ 0. , 1.125, ..., 357.75 , 358.875]  shape(320,)>
------------STR:--------
DimCoord :  longitude / (degrees)
    points: [  0.   ,   1.125, ..., 357.75 , 358.875]
    bounds: [
        [ -0.5625,   0.5625],
        [  0.5625,   1.6875],
        ...,
        [357.1875, 358.3125],
        [358.3125, 359.4375]]
    shape: (320,)  bounds(320, 2)
    dtype: float64
    standard_name: 'longitude'
    long_name: 'longitude'
    var_name: 'lon'
    circular: True
------------------------

------------REPR:-------
<DimCoord: height / (m)  [10.]>
------------STR:--------
DimCoord :  height / (m)
    points: [10.]
    shape: (1,)
    dtype: float64
    standard_name: 'height'
    long_name: 'height'
    var_name: 'height'
    attributes: {'positive': 'up'}
------------------------

Note: I'm busy writing real tests, including hopefully all cases above, so this should make it easier to track any subsequent changes.

[pp-mo]

@lbdreyer attributes

I think this is a good point.
Haven't quite got there, but I'll look into it.
Maybe this one is worth some column-alignment, as that does seem to suit this section in Cube outputs, and IIRC is one of the original reasons to adopt column formatting there.
So, I'm imagining something like

DimCoord :  height / (m)
    points: [10.]
    shape: (1,)
    dtype: float64
    standard_name: 'height'
    long_name: 'height'
    var_name: 'height'
    attributes:
        positive  'up'
        a         1.4
        other     [1.0, 2.2, 3.4]

[pp-mo]

Update : I still havent' done this, but the more I think about it, the more it seems like a good idea.
In the CF world, the attributes exist in the same context as the 'standard' properties of a thing, so it makes sense to put them one-to-a-line, as just suggested.

I think I will prepare a solution for this, which should probably be integrated with the Cube code, but this PR should probably not wait for it.

[lbdreyer]

Whilst reviewing the PR I started having second thoughts about the repr. I'm concerned we're demoting bounds to second class citizens by not including them in the repr.
If anything, I would argue that the bounds matter more than points (if they exist, of course).
The way I see coords is that if bounds exist, the location of the points is (usually!) arbitrary as the data of the cube is valid between the bounds.
Examples, of this:

• If you take an average over a year of daily data, the bounds describe the period over which the average was taken, and the point is usually arbitrarily chosen to be the middle
• when we subset the cube (e.g. with intersection), we primarily consider the bounds

One way to avoid this is to just not include any values in the repr at all. Perhaps instead just include the shape of the points and the bounds for coords, and data for cell measures and ancil vars.

[pp-mo]

Another possibility is to just show when there are bounds, but never give more info than that.
So maybe something like :

<Coord: height / (m)  [1.0, 2.0]  <bounds>  shape(2,)>

or

<Coord: height / (m)  [1.0, 2.0]+bounds  shape(2,)>

But that doesn't address @lbdreyer point above that sometimes the bounds are the important numbers, and not the points.

[pp-mo]

Yet more random ideas ...

<Coord: name / (units)  ["value"]>
<Coord: name / (units)  [1.2]+bounds>
<Coord: name / (units)  [1.2]+bnds[[1.0, 1.5]]>
<Coord: name / (units)  [1.2]+bnds[[1.0, 1.5]]>

<DimCoord: longitude / (degrees)  [ 0. , 1.125, ..., 357.75 , 358.875]  shape(320,)>
<DimCoord: longitude / (degrees)  [ 0. , 1.125, ..., 357.75 , 358.875]  shape(320,(bnds:2))>
<DimCoord: longitude / (degrees)  [ 0., ...]+bnds[[-0.5625, 1.6875], ...]  shape(320,)>

<AuxCoord: x / (days since 2015-05-17)  [2015-06-08 05:20:00]>
<AuxCoord: x / (days since 2015-05-17)  [2015-06-08 05:20:00]  bounds[[2015-05-11 10:40:00, 2015-05-22 13:20:00]]>
<AuxCoord: x / (days since 2015-05-17)  [2015-05-17 00:00:00, ...]+bnds[[2015-05-11 10:40:00, 2015-05-22 13:20:00], ...] shape(10,(bnds:2))>

(Some of these are as-present for reference)
I really don't like any of the ones with bounds much : they don't seem digestible to me.

[wjbenfold]

This seems like a hard problem, and I haven't got a better resolution, just a view on the bounds. I think the repr should inform the user that the bounds exist, because if they know that then they can set out to find more information, but without being told they're there they might not realise. I'm less concerned about how much bounds information is available past that.

[pp-mo]

So, my latest on this is to include an absolutely minimal change, in the spirit of @wjbenfold latest, so you now get reprs like ...

<DimCoord: latitude / (degrees)  [90. , 87.5]  shape(2,)>
<DimCoord: latitude / (degrees)  [90. , 87.5]+bnds  shape(2,)>

<DimCoord: latitude / (degrees)  [90. , 87.5, 85. , 82.5, 80. ]  shape(5,)>
<DimCoord: latitude / (degrees)  [90. , 87.5, 85. , 82.5, 80. ]+bnds  shape(5,)>

<DimCoord: latitude / (degrees)  [90.]+bnds>

<AuxCoord: x / (days since 2015-05-17)  [2015-05-17 00:00:00, ...]+bnds  shape(10,)>

<DimCoord: time / (days since 1850-01-01)  [2046-01-01 12:00:00, ...]+bnds  shape(4,)>
<DimCoord: latitude / (degrees)  [-89.142, -88.029, ..., 88.029, 89.142]+bnds  shape(160,)>
<DimCoord: longitude / (degrees)  [ 0. , 1.125, ..., 357.75 , 358.875]+bnds  shape(320,)>
<DimCoord: height / (m)  [10.]>

( all from the same simple_coord_print_tests.py set as previous things here )

[wjbenfold]

I think I like that for the concise/informative balance. It doesn't feel "clean" but I think that's just because these competing pressures can't all be satisfied at once.

[pp-mo]

Still thinking about fixing the attributes printout to have each one on its own line
I want to be led by the 'Cube' solution, and in any case to have those two work the same.

The Cube method is currently avoiding the use of colons as separators, but looking at it again I'm not sure it is doing such a great job. For instance ...

>>> print(Cube([0], attributes={'int':9, 'float':3.2, 'string':'this info', 'dict':{'a':1, 'b':'two'}}))
unknown / (unknown)                 (-- : 1)
    Attributes:
        dict                        {'a': 1, 'b': 'two'}
        float                       3.2
        int                         9
        string                      this info

>>> print(Cube([0], attributes={'int':9, 'float':3.2, 'string is a really really really long name':'this info', 'dict':{'a':1, 'b':'two'}}))
unknown / (unknown)                                (-- : 1)
    Attributes:
        dict                                       {'a': 1, 'b': 'two'}
        float                                      3.2
        int                                        9
        string is a really really really long name this info
>>> 

What I'm seeing there is that the alignment is not that great, and it needs to quote string values, to avoid confusing the value with the key (!)
We might even re-introduce colons...

unknown / (unknown)                                (-- : 1)
    Attributes:
        dict                                       : {'a': 1, 'b': 'two'}
        float                                      : 3.2
        int                                        : 9
        string is a really really really long name : 'this info'
>>> 

... however, I still think the colons aren't that valuable, it probably looks OK without them, as long as there is a minimum of two spaces ...

unknown / (unknown)                                (-- : 1)
    Attributes:
        dict                                        {'a': 1, 'b': 'two'}
        float                                       3.2
        int                                         9
        string is a really really really long name  "this info"
>>>