There is a python3 hashable problem which I need to deal with, but other than that, I'm pretty keen to get this in v1.3.x. For what it's worth, I've put together a gist which demonstrates the benefit:http://nbviewer.ipython.org/5628989

@efiring - I've added a commit which does some of what you discussed (and more). If it is too extreme, then I'll take it back and be a little more conservative 😉.

I'm also motivated to simplify the color conversion process in matplotlib and to provide a means to create hsv, hsl, hsva and hsvla interpolated color schemes easily. I'm tempted to hold fire on this and do it in v1.4 though (along with deprecating the use of Colormap.set_bad etc.,).

What do you think?

I think we should hold for 1.4 any further features at this point. (The feature freeze began almost two weeks ago now, and I've let a few things slide through, but we're mainly in the mode of polishing and bugfixing the features we already have at this point.)

I'll leave it to@efiring to give this one more look over and merge.

@pelson,@mdboom, there are lots of good ideas in here, but also some radical changes that I think deserve discussion, so I am not willing to merge this as-is. Most of it may be more appropriate for 1.4 than for 1.3 at this late stage.

The biggest strategy change here is includingpeek() as a method of the Colormap. Having apeek method or function is a great idea, but making it a Colormap method, and yet including all the high level pyplot functionality while not even returning the figure object, seems to me like a questionable design. Everywhere else, we have tried to keep some high-level to low-level hierarchy. To be consistent with that logic,peek should be a pyplot function, perhapsview_colormap(cbar). (Longer term, it would be nice to have a colormap-editing widget instantiated by a pyplot function.) Having it as a pyplot function would also make it more discoverable.

The decorator gymnastics in the present PR are also getting a bit hard to follow, and I don't think they actually save any LOC or clarify anything, compared to simply repeating the phrase,

ifself._isinit:self._set_extremes()

three times, which amounts to 6 LOC, versusmany more for the definition of the decorator plus its three invocations. With all the switching around ofself andfunc, that decorator begins to resemble a textbook example of obfuscated code.

I don't disagree with the analysis@efiring. Some of the things in here are a little contravertial and have no place in v1.3, but I do feel quite passionately about the underlying purpose for this PR making it in (the function from_levels_and_colors which avoids users, i.e. my colleagues, accidentally mis-representing their data by misconstructing Norms and Cmaps for quantised levels.). The first commit on this PR does that, without introducing any controversial changes - perhaps that is the way to go here.

Ok. This has been reverted to the first commit (my original changes are in a branchhttps://github.com/pelson/matplotlib/tree/colormap_api_for_v1.4 if anybody is interested).

@pelson, for the purpose of inclusion in 1.3, I recommend that you remove the new properties. At this stage, they would represent a commitment to a new API, which might be a good one (basically, I like it), but which is incomplete, and which contributes absolutely nothing to the purpose of the PR--no functionality, no reduction in LOC, no improvement in readability or performance.

You might even go so far as to put an "Experimental" tag in the docstring of your new function, to leave a little wiggle-room. I think this would be wise, given the very short review period that has been available.

I've now reverted all of the API changes on Colormap.