PEP8 issue:

AssertionError: Found code syntax errors (and warnings):
/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/matplotlib-1.5.dev1-py2.7-linux-x86_64.egg/matplotlib/cm.py:56:25: E203 whitespace before ':'

Tagged as 2.0 as a) it is coming 'soon' to change the default color map anyway b) independent of if you like it or not, this sort of change is the local working definition of backwards incompatible changes .

Ok, I fixed the spacing issue.

It was said that "dumping them in as if they were continuous was a mistake", so this could be considered a bugfix rather than a new feature, but 2.0 is fine. I like whatever you like. :)

Any ideas on how to implement this correctly instead of using the dictionary label hack? Should they be in a separate dictionary than datad?

We are doing violence and breaking back-compatibility on colors so this is a good time to do this. Once someone relies on a bug it becomes a feature ;)

Could you also add a note in whats_new and api_changes explaining this change?

Would it be better to store the color map values in a npy file that we bundle rather than as text (which would deal with the 1.000000000001 issues you cleaned up a bit more elegantly.

Note that these colormaps (and flag) have uses: i am sometimes more intrested in value change of a data set, and these give a nice approximation of the derviate.

Could you also add a note in whats_new and api_changes explaining this change?

Under a heading of version 2.0?

Would it be better to store the color map values in a npy file that we bundle rather than as text

I would prefer they stay as text for transparency of where they come from, and ease of editing in situations like this.

Yes, please create a new heading for 2.0

Fair enough re text vs npy files.

On Wed, Mar 18, 2015 at 11:54 PM endolith notifications@github.com wrote:

Could you also add a note in whats_new and api_changes explaining this
change?

Under a heading of version 2.0?

Would it be better to store the color map values in a npy file that we
bundle rather than as text

I would prefer they stay as text for transparency of where they come from,
and ease of editing in situations like this.

—
Reply to this email directly or view it on GitHub
#3973 (comment)
.

@endolith Any chance of getting the whats_new/api_changes entries?

Do you think it is worth including instructions on how to convert these back to the continuous versions?

I started to, but wasn't sure about the format:

doc/users/whats_new.rst:

.. _whats-new-2-0:

new in matplotlib-2.0
=====================

Colormaps
---------
Colorbrewer's "qualitative" colormaps ("Accent", "Dark2", "Paired", 
"Pastel1", "Pastel2", "Set1", "Set2", "Set3") are now implemented
as ``ListedColormap`` instead of ``LinearSegmentedColormap``.
This way, they can be used for maps such as chloropleths or
labeled images.

.. _whats-new-1-5:

doc/api/api_changes.rst:

Changes in 2.0.x
================

???

Changes in 1.4.x
================

@endolith , we have new instructions on how to create these entries: https://github.com/matplotlib/matplotlib/blob/master/doc/api/api_changes/ and https://github.com/matplotlib/matplotlib/tree/master/doc/users/whats_new

Should this be rebased on to color_overhaul?

I'm still not sure what to say in API changes, though. You would still use the same commands to use these colormaps, no?

Actually, this doesn't behave as I would expect it to.

for n in xrange(12):
    subplot(11, 1, n)
    imshow([arange(n)], cmap='Dark2', interpolation='nearest')
    plt.axis('off')

I would expect this to interpolate with the LinearSegmentedColormap, which it does:

but then with the ListedColormap, I expected it to use the colors as indexed, but that's not how it works:

like I would expect the second row to be green then brown, the third to be green brown blue, and so on, with gray not showing up at all until the row is [0, 1, 2, 3, 4, 5, 6, 7]. I'm misunderstanding ListedColormap?

Try adding the kwarg norm=mpl.colors.NoNorm. That will pass the integers through for indexing. Otherwise the default Normalize will scale them just like any other sequence.

That works:

for n in xrange(12):
    plt.subplot(11, 1, n)
    plt.imshow([arange(n)], cmap='Dark2', norm=colors.NoNorm(),
                interpolation='nearest')
    plt.axis('off')

Without the parentheses gives an AssertionError. This should raise an actual exception with a meaningful message, right?

  File "C:\Python27\lib\site-packages\matplotlib\axes\_axes.py", line 4636, in imshow
    assert(isinstance(norm, mcolors.Normalize))

AssertionError

Yes, you are correct. I think this is one of the arguments for using traitlets--that it will facilitate catching this sort of error early, and with a clear error message. As I understand it, assert is more of a developer's tool--a way of checking assumptions, not of catching users' errors.

(Oh nevermind that was fixed already)

Also rebased and added notes to whatsnew and apichanges

So should these be moved to the new _cm_listed.py file created by #4707? The intention of ListedColormap is not what I expected, but still the most appropriate for these sets of data.

Since you're changing so many colour map lines, would it be possibly to wrap them so that all 3 elements of the tuple were on the same line instead of the haphazard wrapping that occurs right now?

@QuLogic Can you point out exactly which line you're referring to? The ones I added have all 3 on the same line.

Here's one for example from 4d547af.

You mean change the dicts to lists of RBG tuples? I could do that, but it should be a separate PR. I was thinking I should remove the 0.90000000000000002 → 0.9 tweaks to a separate PR anyway, for clarity.

I rewrote them all as RGB lists and force-pushed.

I take it you also removed the other tweaks to put in a separate PR later, then?

They were all in this range and overwritten, actually (except one I missed and will now push again)

I went through these with a small script to check the values and I don't see anything incorrect. The data in the ColorBrewer section is much neater now. I don't see why this can't be merged and backported (or maybe re-opened directly to 2.x.)

Over a year, but it got in!

backported to v2.x as c27dd78