Here are some examples of the figure, respectively with thegrayscale,ggplot anddark_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 commitfe0abf7 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…

ApparentlyrcParams['axes.color_cycle'] is deprecated so I switched torcParams['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 determiningmax_idx.

Seehttp://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 oncycler, I was unsuccessfully looking for this yesterday. I must have googled the wrong keywords… Furthermore, I didn't know thatzip truncates the returned list of tuples to the size of the shortest argument, so indeed it will avoid bothering withmax_idx.

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

forsty_dict,jinzip(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 torcParams['axes.prop_cycle'] than just the color cycle : what about**ing kwargs that are not supported bypatches.Circle (likemarker)?

@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 changedplot_colored_circles with what I suggested earlier, rather than exactly what you proposed (about using thecycler). 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 thatscatter 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.

Agrep tells me that (currently) thefivethirtyeight and theclassic styles tweak some of the rcParams related tofigure.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 usingplot instead ofscatter 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 usestight_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 usescatter instead ofplot in the functionplot_scatter (which seems more logical to me). Unfortunately, when I replace the current line (l. 17)ax.plot(x, y, ls='none', marker=marker) withax.scatter(x, y, marker=marker), I get the following traceback :

In [2]:%tb---------------------------------------------------------------------------ValueErrorTraceback (mostrecentcalllast)/home/adrien/matplotlib/lib/matplotlib/backends/backend_agg.pycindraw(self)462463try:-->464self.figure.draw(self.renderer)465finally:466RendererAgg.lock.release()/home/adrien/matplotlib/lib/matplotlib/artist.pycindraw_wrapper(artist,renderer,*args,**kwargs)66defdraw_wrapper(artist,renderer,*args,**kwargs):67withwith_rasterized(artist,renderer):--->68returndraw(artist,renderer,*args,**kwargs)6970draw_wrapper._supports_rasterization=True/home/adrien/matplotlib/lib/matplotlib/figure.pycindraw(self,renderer)12601261mimage._draw_list_compositing_images(->1262renderer,self,dsu,self.suppressComposite)12631264renderer.close_group('figure')/home/adrien/matplotlib/lib/matplotlib/image.pycin_draw_list_compositing_images(renderer,parent,dsu,suppress_composite)137ifnot_compositeornothas_images:138forzorder,aindsu:-->139a.draw(renderer)140else:141# Composite any adjacent images together/home/adrien/matplotlib/lib/matplotlib/artist.pycindraw_wrapper(artist,renderer,*args,**kwargs)66defdraw_wrapper(artist,renderer,*args,**kwargs):67withwith_rasterized(artist,renderer):--->68returndraw(artist,renderer,*args,**kwargs)6970draw_wrapper._supports_rasterization=True/home/adrien/matplotlib/lib/matplotlib/axes/_base.pycindraw(self,renderer,inframe)2377renderer.stop_rasterizing()2378->2379mimage._draw_list_compositing_images(renderer,self,dsu)23802381renderer.close_group('axes')/home/adrien/matplotlib/lib/matplotlib/image.pycin_draw_list_compositing_images(renderer,parent,dsu,suppress_composite)137ifnot_compositeornothas_images:138forzorder,aindsu:-->139a.draw(renderer)140else:141# Composite any adjacent images together/home/adrien/matplotlib/lib/matplotlib/artist.pycindraw_wrapper(artist,renderer,*args,**kwargs)66defdraw_wrapper(artist,renderer,*args,**kwargs):67withwith_rasterized(artist,renderer):--->68returndraw(artist,renderer,*args,**kwargs)6970draw_wrapper._supports_rasterization=True/home/adrien/matplotlib/lib/matplotlib/collections.pycindraw(self,renderer)819defdraw(self,renderer):820self.set_sizes(self._sizes,self.figure.dpi)-->821Collection.draw(self,renderer)822823/home/adrien/matplotlib/lib/matplotlib/artist.pycindraw_wrapper(artist,renderer,*args,**kwargs)66defdraw_wrapper(artist,renderer,*args,**kwargs):67withwith_rasterized(artist,renderer):--->68returndraw(artist,renderer,*args,**kwargs)6970draw_wrapper._supports_rasterization=True/home/adrien/matplotlib/lib/matplotlib/collections.pycindraw(self,renderer)312313ifdo_single_path_optimization:-->314gc.set_foreground(tuple(edgecolors[0]))315gc.set_linewidth(self._linewidths[0])316gc.set_linestyle(self._linestyles[0])/home/adrien/matplotlib/lib/matplotlib/backend_bases.pycinset_foreground(self,fg,isRGBA)1027self._rgb=fg1028else:->1029self._rgb=colors.to_rgba(fg)10301031defset_graylevel(self,frac):/home/adrien/matplotlib/lib/matplotlib/colors.pycinto_rgba(c,alpha)137rgba=_colors_full_map.cache[c,alpha]138except (KeyError,TypeError):# Not in cache, or unhashable.-->139rgba=_to_rgba_no_colorcycle(c,alpha)140try:141_colors_full_map.cache[c,alpha]=rgba/home/adrien/matplotlib/lib/matplotlib/colors.pycin_to_rgba_no_colorcycle(c,alpha)196c=c[:3]+ (alpha,)197ifany(elem<0orelem>1foreleminc):-->198raiseValueError("RGBA values should be within 0-1 range")199returnc200ValueError:RGBAvaluesshouldbewithin0-1range

It is a bit weird as it seems to occur only withseaborn-colorblind andseaborn-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 onplot with 'none' line style instead of usingscatter…

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 usesorted(plt.style.available) instead of simplyplt.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 for2af4445 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 outsideplot_figure…

More importantly, with commitc2347d1, styles are now usedmore or less in alphabetical order: onlydefault andclassic are given specific roles (= the 2 first positions). NB: I have addeddefault eventhough it is not inplt.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 via992b5ee.