Here are some examples of the figure, respectively with the grayscale, ggplot and dark_background style:
grayscale.pdf
ggplot.pdf
dark_background.pdf

Note to myself: it may be clever to add x- and y-label for at least one of the subplots.

Added some demo of the axes labels in the first subplot.

Besides, I hope I didn't miss any of the PEP8 errors.

The PEP8 tests are now fine. However, since my last commit fe0abf7 that only corrected PEP8 typos, test_backend_pdf.test_grayscale_alpha is failing on Travis and I don't understand why. And about the other failure on AppVeyor, I don't even clearly understand where it fails…

Apparently rcParams['axes.color_cycle'] is deprecated so I switched to rcParams['axes.prop_cycle'].by_key()['color'] to force the colors of the circle patches. However, I'm not sure I've totally understood how to use the cycler…

I also corrected a typo when determining max_idx.

See http://matplotlib.org/cycler/

cycler started life as a mpl PR that was deemed to have use outside of the library (which it does, we use it a couple of different places at my day job). For this exact use case it is a bit overkill, for multi-style (ex 'lw', 'ls', 'color', 'marker') it is pretty useful.

also 👍 on this!

@tacaswell : thanks for the doc on cycler, I was unsuccessfully looking for this yesterday. I must have googled the wrong keywords… Furthermore, I didn't know that zip truncates the returned list of tuples to the size of the shortest argument, so indeed it will avoid bothering with max_idx.

However, in this specific example, I'd rather do something like

for sty_dict, j in zip(plt.rcParams['axes.prop_cycle'], range(nb_samples)):
    ax.add_patch(Circle(prng.normal(scale=3, size=2),
                        radius=1.0, color=sty_dict['color']))

rather than **ing. At least if one wants to demonstrate only the color cycle in the subplot with the circle patches. I am a bit afraid of style sheets that might add other properties to rcParams['axes.prop_cycle'] than just the color cycle : what about **ing kwargs that are not supported by patches.Circle (like marker)?

@QuLogic : thank you for all the comments and remarks! I did the suggested modifications.

@tacaswell : normally, rcParams['axes.color_cycle] is not used anywhere, replaced by all the new way of selecting colors ("Cn", rcParams['axes.prop_cycle]). I also changed plot_colored_circles with what I suggested earlier, rather than exactly what you proposed (about using the cycler). But if you think your proposition is better, no problem I'll modify the function accordingly.

From the plotting point of view, I added a 2nd cloud of points in the scatter subplot: (i) to convince myself that scatter was indeed using the current color cycle, (ii) because it adds some insight on how each style helps to discriminate different clusters of points. For this 2nd point, see for example

where the green cluster is a bit hard to distinguish from the blue one, while with this other style

the two clusters appear much more clearly.

The subplot spacing still needs to be adjusted. Don't know if that should be in the script, or elsewhere, though.

A grep tells me that (currently) the fivethirtyeight and the classic styles tweak some of the rcParams related to figure.subplot.*. If I impose some of these rcParams in the script (and try to find some values that look nice on all the currently available styles), it will affect the behavior of these styles, won't it? Is it what we want? For the moment, the script avoids to overwride anything that may be tuned by a style, in order for the comparison betweeen the different styles to be the fairest possible.

Anyway, I've just seen some typos + that the script is using plot instead of scatter to do a scatter plot, so I will try to update the script tomorrow.

@afvincent What is the status on this one? Looks like something that would be nice to land for 2.0

@WeatherGod : the script now uses tight_layout, which fixes most of the subplot spacing issues. The only remaining one I noticed is the suptitle being sometimes (just) a bit too close from the top center subplot.

@jenshnielsen : there is still one issue that I am struggling with. I would llike to use scatter instead of plot in the function plot_scatter (which seems more logical to me). Unfortunately, when I replace the current line (l. 17) ax.plot(x, y, ls='none', marker=marker) with ax.scatter(x, y, marker=marker), I get the following traceback :

In [2]: %tb
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
/home/adrien/matplotlib/lib/matplotlib/backends/backend_agg.pyc in draw(self)
    462 
    463         try:
--> 464             self.figure.draw(self.renderer)
    465         finally:
    466             RendererAgg.lock.release()

/home/adrien/matplotlib/lib/matplotlib/artist.pyc in draw_wrapper(artist, renderer, *args, **kwargs)
     66     def draw_wrapper(artist, renderer, *args, **kwargs):
     67         with with_rasterized(artist, renderer):
---> 68             return draw(artist, renderer, *args, **kwargs)
     69 
     70     draw_wrapper._supports_rasterization = True

/home/adrien/matplotlib/lib/matplotlib/figure.pyc in draw(self, renderer)
   1260 
   1261         mimage._draw_list_compositing_images(
-> 1262             renderer, self, dsu, self.suppressComposite)
   1263 
   1264         renderer.close_group('figure')

/home/adrien/matplotlib/lib/matplotlib/image.pyc in _draw_list_compositing_images(renderer, parent, dsu, suppress_composite)
    137     if not_composite or not has_images:
    138         for zorder, a in dsu:
--> 139             a.draw(renderer)
    140     else:
    141         # Composite any adjacent images together

/home/adrien/matplotlib/lib/matplotlib/artist.pyc in draw_wrapper(artist, renderer, *args, **kwargs)
     66     def draw_wrapper(artist, renderer, *args, **kwargs):
     67         with with_rasterized(artist, renderer):
---> 68             return draw(artist, renderer, *args, **kwargs)
     69 
     70     draw_wrapper._supports_rasterization = True

/home/adrien/matplotlib/lib/matplotlib/axes/_base.pyc in draw(self, renderer, inframe)
   2377             renderer.stop_rasterizing()
   2378 
-> 2379         mimage._draw_list_compositing_images(renderer, self, dsu)
   2380 
   2381         renderer.close_group('axes')

/home/adrien/matplotlib/lib/matplotlib/image.pyc in _draw_list_compositing_images(renderer, parent, dsu, suppress_composite)
    137     if not_composite or not has_images:
    138         for zorder, a in dsu:
--> 139             a.draw(renderer)
    140     else:
    141         # Composite any adjacent images together

/home/adrien/matplotlib/lib/matplotlib/artist.pyc in draw_wrapper(artist, renderer, *args, **kwargs)
     66     def draw_wrapper(artist, renderer, *args, **kwargs):
     67         with with_rasterized(artist, renderer):
---> 68             return draw(artist, renderer, *args, **kwargs)
     69 
     70     draw_wrapper._supports_rasterization = True

/home/adrien/matplotlib/lib/matplotlib/collections.pyc in draw(self, renderer)
    819     def draw(self, renderer):
    820         self.set_sizes(self._sizes, self.figure.dpi)
--> 821         Collection.draw(self, renderer)
    822 
    823 

/home/adrien/matplotlib/lib/matplotlib/artist.pyc in draw_wrapper(artist, renderer, *args, **kwargs)
     66     def draw_wrapper(artist, renderer, *args, **kwargs):
     67         with with_rasterized(artist, renderer):
---> 68             return draw(artist, renderer, *args, **kwargs)
     69 
     70     draw_wrapper._supports_rasterization = True

/home/adrien/matplotlib/lib/matplotlib/collections.pyc in draw(self, renderer)
    312 
    313         if do_single_path_optimization:
--> 314             gc.set_foreground(tuple(edgecolors[0]))
    315             gc.set_linewidth(self._linewidths[0])
    316             gc.set_linestyle(self._linestyles[0])

/home/adrien/matplotlib/lib/matplotlib/backend_bases.pyc in set_foreground(self, fg, isRGBA)
   1027             self._rgb = fg
   1028         else:
-> 1029             self._rgb = colors.to_rgba(fg)
   1030 
   1031     def set_graylevel(self, frac):

/home/adrien/matplotlib/lib/matplotlib/colors.pyc in to_rgba(c, alpha)
    137         rgba = _colors_full_map.cache[c, alpha]
    138     except (KeyError, TypeError):  # Not in cache, or unhashable.
--> 139         rgba = _to_rgba_no_colorcycle(c, alpha)
    140         try:
    141             _colors_full_map.cache[c, alpha] = rgba

/home/adrien/matplotlib/lib/matplotlib/colors.pyc in _to_rgba_no_colorcycle(c, alpha)
    196         c = c[:3] + (alpha,)
    197     if any(elem < 0 or elem > 1 for elem in c):
--> 198         raise ValueError("RGBA values should be within 0-1 range")
    199     return c
    200 

ValueError: RGBA values should be within 0-1 range

It is a bit weird as it seems to occur only with seaborn-colorblind and seaborn-dark-palette. I rapidly had a look to the 2 style sheets : the color declarations seem to be correct hexadecimal code. So my current workaround is to rely on plot with 'none' line style instead of using scatter…

PS : there are many more styles now than when I wrote this script the first time. The number of figures generated will be rather big : should we worry about that?

My last commit (610ce04) reverts some of my previous changes in the docstrings. I don't know why I was sure the docstrings were supposed to be written """Does something…""" rather than """Do something…""", but reading again PEP 257 and Numpy documentation guide style, I realized I had remembered them totally backwards… Sorry for the noise!

I'm wondering if how it's currently laid out, it might end up being a little difficult for people to compare...What about laying it out in a table, as such

stylesheet name  (possibly rotated) | line plot+annotation | scatter plot | heat map| bar

And yes, I kinda think you can safely reduce the number of plots if broad style changes are what you're going for.

@story645 I have just experimented a bit with your suggestion about a tabular layout : one issue that arises is the figure-related rcParams (in particular the face color for style with dark background). I will try to make a draft with one figure per face color value today.

Sorry, this PR had fallen below my radar…

I switched to a single row of demo plots as @story645 suggested, and indeed it looks nice (though I have kept all the previous demo plots). Actually, I have decided to stick to one figure per style, instead of one figure per figure face color: it makes the code simpler to read, and some style share the same face color but differ on other figure parameters (so this approach was not totally consistent).

Here are some examples showing how it currently looks like:

Is it a problem if I try to rebase the branch of this PR? It seems like I started working on this before top and right ticks were set to not visible by default… Beside some auto ticks are a bit weird but they may have been enhanced since last May.

@NelleV Is the script new docstring OK for you :)?

FYI, I rebase the code of my branches all the time, so don't hesitate :)

Simple rebase. (Unfortunately I might have missed to pass some option to have the possibility of squashing some minor commits.) As expected, the ticks behave better with the current master. Here is now the kind of comparison that can be done with this new example script:

One last thing I am wondering about the gallery behavior: the figures are displayed in the order they are created, aren't they? If that the case, maybe I should use sorted(plt.style.available) instead of simply plt.style.available, at least to group all the seaborn-related styles together?

Agree that like styles should be grouped together, but I think classic should always be on top. Also 😄 about the new layout.

Oops: the complete commit message for 2af4445 should be "Fix default value of the named parameter in 'plot_figure'". As I am not sure how ugly it is to amend a pushed commit, I let it as it is for the moment: if it was not something to do, just tell me and I will look how to take care of it through git. Anyway, this commit is pretty minor: I just realized that the keyword argument default value was not so clever anymore, as the style context manager is now outside plot_figure…

More importantly, with commit c2347d1, styles are now used more or less in alphabetical order: only default and classic are given specific roles (= the 2 first positions). NB: I have added default eventhough it is not in plt.style.available, because I find it rather useful to know what the defaults look like compared to the other styles.

I am still opened to remarks and suggestions, in case this example needs some additional polishing step.

Edit: typo, plt.style.default ← plt.style.available

I am not very good at reading CI failure reports but I think the Appveyor one is of the usual “502 gateway”-type, while the Travis one:

Warning, treated as error:
/home/travis/build/matplotlib/matplotlib/doc/thirdpartypackages/index.rst:20: WARNING: duplicate label hl_plotting, other instance in /home/travis/build/matplotlib/matplotlib/doc/mpl_toolkits/index.rst

is unrelated to this PR and was fixed by #7304 .

While I am more than happy to merge with an appveyor failure, I am less happy about the travis error. Do you mind rebasing?

@NelleV I've just rebased my branch. Let's see if Travis is still complaining.

Edit: Travis seems happy now :).

Backported to v2.x via 992b5ee.