hannah

> bivariate_pcolormesh I'd be very against this b/c it would very quickly grow to bivariate_*{every method that takes a scalermappable} b/c theoretically every method that takes a univariate colormap should...

> Which other methods do you think would look good with a bivariate colormap? Honestly look good is besides the point - I think the library should facilitate creating visualizations...

1) try to guess that the input data are shaped in such a way that the user wants a bivariate colormap I don't see why we can't make this explicit?...

> To me, that sounds worse for the user: ```python cmap = bivariate_cmap(cmap1, cmap2) norm = bivariate_norm(norm1, norm2) ndata = np.stack([data1, data1]) ax.pcolormesh(data, norm=norm, cmap=cmap, kwargs=kwargs) ``` This seems great...

> Units are the prime example of why I think this is a bad idea! Our unit support is a brittle, inconsistent mess. Yes because we do it on a...

On thing we could do on the NColorNorm case is have the user specify which dimensions map to which maps when calling the constructor? Not sure that solves the unpacking...

> I could code up the explicit method in about 30 minutes and have a PR in a day I think there are good enough third party solutions that it's...

>you will have to pardon any ignorance if the following is a bad idea, but I don't see why an explicit implementation cannot be developed first, and the implicit api...

doc build failure mystifies me cause builds locally

And it's an important doc build since it's the style example and unicode_minus keyword :/