It looks like part of the point here is that a colorbar always has an axes attribute, so there is no need for a tuple in the ScalarMappable colorbar attribute.

Looks like a good cleanup--but it is a bit dangerous, and I don't know how to handle that. The danger, of course, is that some user code is expecting the attribute to hold a tuple. Maybe it will be adequate to simply flag this prominently in the description of API changes.

Looks like a good cleanup--but it is a bit dangerous, and I don't know how to handle that. The danger, of course, is that some user code is expecting the attribute to hold a tuple. Maybe it will be adequate to simply flag this prominently in the description of API changes.

Agreed. Indeed I have code which does cb = scalarmappable.colorbar[0]. But I'm prepared to accept the fact that this is a backwards incompatible change - having anything but a colorbar instance in a colorbar attribute is just wrong. An api_changes.rst entry is the best I can come up with too - but I think this attribute is sufficiently opaque that you would only know about it if you read the source code of cm.ScalarMappable.

Think this is good to go.

As a note, since this is a backwards incompatible change, should the next version number be 2.0.x?

Since 1.0, we have allowed backward incompatible changes of this magnitude for minor point releases, with a note in api_changes.rst and a deprecation process when necessary. So I don't think this requires 2.0.x. I think we should save that for the time when a significant portion of user code would require changes -- this is a bit of a corner case.