"BivariateNorm" just so that it can follow the mpl convention of "Xnorm"?

is there are a reason norm_instances = none and is not:

def __init__(self, norm1 = None, norm2 = None):

No reason. I think what you are proposing is more convenient from user's perspective.

How do you handle the use case [BoundaryNorm(), None] or [None, BoundaryNorm]?

Yes this should be handled.

This is being handled now.

try to stick to pep8 (is_bivar)
also this can br written as isinstance(norm, (mcolors.BivariateNorm, mcolors.BivariateColormap))
(similarly below)

Updated.

The previous change was reverted because two different variables norm and cmap are being checked for their respective instances.

Unless there is a strong reason to expose them, attributes should be private (start with an underscore) by default. Otherwise, they all become part of the public API, which is very difficult to change while maintaining back-compatibility.
(Same comment throughout the PR.)

Any specific attribute you are pointing to? I tried to keep it similar to ColorbarBase class.

ax is probably fine to stay public (it is public on every Artist), but the xvalues, xboundaries, etc can probably be made private.

shouldn't BivariateNorm subclass Normalize? 'specially since now it's normalizing down to a 1d space?

BivariateNorm does not inherit anything from Normalize so I thought it should not subclass it.

With the new design, BivariateNorm should havel all the same classes as Normalize...and I think subclassing it so it's registered generically as a Norm is preferable to having to treat it as a special case when it doesn't need to be.

This can be done with an ABC https://docs.python.org/3/library/abc.html#abc.ABCMeta.register which both Normalize and BivariateNorm register with.

Sure, but I don't see a reason why BivariateNorm shouldn't be subclassing Norm as it has the same architecture as any other norm...take data (scaler or vector)->map to 1D lut value ->get color, and color ->lut->scaler/vector.

If the code paths are completely different, why force the sub-class? In general, sub-classing is only worth it when you can share significant amounts of implementation details, otherwise duck-typing is better.

My point is mostly that the code paths shouldn't end up being all that different and more to the point in mpl land there's probably a ton of code that checks if things are norms and if this code works in those instances it doesn't make sense to change all that code to cover both cases when this is still fundamentally a norm. But I think I'm on the same page as you on the solution maybe being a "Norm" metaclass.

can you guarantee that this scheme always yields uniqueness?
(I'm confused about what's going on here and sort of have been thinking about a more general mapping between nd arrays and numbers wherein you get a sorted unique list of the nd tuples in the dataset so that the lookup/map is just the index of the value in the sorted list.

Since after normalization every variable ends up between 0 to 1. So here I am changing it to index flattened 1d lut of BivariateColormap by mapping 0-1 to 1 to 256*256. Here I am currently hardcoding 256 as number of rows and columns in lut of 2d colormap. But this should be changed somehow to use N attribute of BivariateColormap.

This is column major indexing (row * num_cols + col is c / numpy style, col * num_rows + row).

I am more concerned that the descritization is happening here rather than in the color map (which is done https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/colors.py#L483) which prevents the size of the colormap from having to be known by the norm.

Why can't this return a Nd array? I think the most important places the norm and color map are called is https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/cm.py#L209 and
https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/image.py#L365 . In the first case it can be blindly passed through and in the second that resampling needs to happen over each plane.

In the case of the color bar, that already needs to be heavily special cased.

20:11 $ git grep '\.norm[ (]' | grep -v linalg
lib/matplotlib/cm.py:        self.norm = norm
lib/matplotlib/cm.py:            x = self.norm(x)
lib/matplotlib/cm.py:        self.norm = norm
lib/matplotlib/collections.py:        self.norm = other.norm
lib/matplotlib/colorbar.py:            y = self.norm(self._boundaries.copy())
lib/matplotlib/colorbar.py:            b = self.norm(self._boundaries, clip=False).filled()
lib/matplotlib/colorbar.py:            xn = self.norm(x, clip=False).filled()
lib/matplotlib/colorbar.py:        self.norm = mappable.norm
lib/matplotlib/colorbar.py:                                       facecolor=self.cmap(self.norm(val)),
lib/matplotlib/image.py:                A = self.norm(A)

I am still a bit concerned that the descritization is being done here rather than in the color map. Won't this break for any colormap which is not 256 by 256?

This can be done with an ABC https://docs.python.org/3/library/abc.html#abc.ABCMeta.register which both Normalize and BivariateNorm register with.

Doing this here means you can not change anything about the color map or norm later.

Removed this.

Why would the norm ever be a colormap?

Thanks for pointing this out. Fixed now.

Why do this up-front? defering all of this to _make_image means the colormap and norm and be updated.

Check now.

Don't need any of the classic shims as there is no back-compatibility to maintain.

Removed.

Probably better to factor this as def _make_ticker(norm, values, boundaries, locator, formatter): as a local function in update_ticks.

You mean local/private function of class or nested function?

nested function

Done.

This is column major indexing (row * num_cols + col is c / numpy style, col * num_rows + row).

I am more concerned that the descritization is happening here rather than in the color map (which is done https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/colors.py#L483) which prevents the size of the colormap from having to be known by the norm.

Why can't this return a Nd array? I think the most important places the norm and color map are called is https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/cm.py#L209 and
https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/image.py#L365 . In the first case it can be blindly passed through and in the second that resampling needs to happen over each plane.

In the case of the color bar, that already needs to be heavily special cased.

20:11 $ git grep '\.norm[ (]' | grep -v linalg
lib/matplotlib/cm.py:        self.norm = norm
lib/matplotlib/cm.py:            x = self.norm(x)
lib/matplotlib/cm.py:        self.norm = norm
lib/matplotlib/collections.py:        self.norm = other.norm
lib/matplotlib/colorbar.py:            y = self.norm(self._boundaries.copy())
lib/matplotlib/colorbar.py:            b = self.norm(self._boundaries, clip=False).filled()
lib/matplotlib/colorbar.py:            xn = self.norm(x, clip=False).filled()
lib/matplotlib/colorbar.py:        self.norm = mappable.norm
lib/matplotlib/colorbar.py:                                       facecolor=self.cmap(self.norm(val)),
lib/matplotlib/image.py:                A = self.norm(A)

The different signature from the ColorBar base class is a bit problematic, but not sure what to do about it.

perhaps set_labels(self, xylabel) (where xylabel=(xlabel, ylabel)); set_xlabel; set_ylabel?
let set_label raise an error
this likely would play better with traitlets

This may be better done as np.asarray([c.ravel() for c in C]) to be a bit future proof.

We have a style preference for using () for continuation rather than \ so

msg = ('...' +
       '...')

The + is not needed.

Done.

use_underscores_notCapsForVariables

Changed isBivari to is_bivari.

should check ndim == 2 in this case?

just self._xlabel = xlabel should be enough (unless we explicitly want to support any object via conversion to string, and even then str(xlabel) is clearer.

Just imitating how it is done in ColorbarBase.set_label.

definitely wrong on Py3
use six
should have been caught by pycodestyle perhaps?

Fixed now.

What happens when the input is shape (2, 3, 4)?

This sort of ambiguity should be avoided (and indicates that this API is probably not the right design choice).