I wonder whether we should make this chance, or instead introduce interactive mode here, which wouldn't require the use of show at all (at least when working from an interactive console). I think that's the assumption that many of these examples are under.

Introducing interactive mode at the beginning may not be the best idea. Placing a comment that the show() command isn't needed in interactive mode may be a better option. If you really want to do that then you should probably take out the show() from the 2 examples which already have it. It is inconsistent and confusing otherwise.

Anyways its your library. Just saying that having an inconsistent documentation(read incorrect for new users) isn't good for getting new users. And this mistake is in the first page about using the library.

Ok -- I don't feel strongly either way. @WeatherGod, @efiring: thoughts?

The issue we have here is that the two particular examples in question are/could be in use elsewhere. Yes, having mixed styles is bad, but we can't just eliminate the show() call as it might be used elsewhere in a non interactive context. Because we have largely solved the show() problems that have plagued us from v1.0 and earlier, I vote for a more liberal use of show(). It would work regardless of the code being used in an interactive mode or not, so users are less likely to be confused when the copied and pasted code doesn't work in their scripts.

Ok, then. I'm going to merge and backport to v1.3.x.

How often is the online documentation built? It isn't updated yet.

It's normally only update with each release, but it's probably worth doing an update now in any event.