Matplotlib & Seaborn

This is the engine-room post. The goal is to replace mystery with mechanism: once you understand the object hierarchy and the two ways to call into it, the confusing behaviors that plague beginners become predictable. Most plotting bugs are really questions of which object you're addressing.

The cover promises that learning the model lets you debug any plot in seconds, which is the genuine payoff of this material.

The three-layer hierarchy is the backbone of Matplotlib. A Figure is the top-level container — the entire image or window. It holds one or more Axes, each a self-contained plotting region with its own data, coordinate system, and ticks. Each Axes in turn holds Artists: the concrete drawn objects like lines, bars, text, and patches.

Everything visible in a Matplotlib chart is an Artist sitting on some Axes inside some Figure. Once you hold that sentence in your head, customization becomes a matter of locating the right object in the tree.

The tree diagram shows the containment explicitly: a Figure with an Axes child, and the Axes holding a Line2D, the Text objects for titles and labels, and the Axis objects that manage ticks and spines. This is literally the object graph Matplotlib builds in memory when you plot.

The practical use of the tree is navigation. To change a tick, you go to the Axis. To change a title, you go to the Axes' Text. To resize the whole thing, you go to the Figure.

Matplotlib offers two ways to issue commands, and confusing them is a top source of frustration. The pyplot (stateful) API — plt.plot, plt.title — operates on an implicit 'current' Figure and Axes that Matplotlib tracks behind the scenes. It's quick for one-off scripts and notebook cells. The object-oriented API makes you create the Figure and Axes explicitly and call methods on them.

The stateful API feels easier at first but breaks down with multiple subplots, where 'current' becomes ambiguous. The object-oriented style is more verbose but unambiguous, which is why it's the recommended style for any code that matters.

This code slide demonstrates the object-oriented style you should default to. fig, ax = plt.subplots() hands you both objects explicitly. From there every command names its target: ax.plot, ax.set_title, ax.set_xlabel, ax.legend, and fig.savefig. There is never any doubt about which Axes a setting lands on.

This pattern scales directly to multiple subplots — plt.subplots(2, 2) returns a grid of Axes — without changing how you think. Learning it early is the highest-leverage Matplotlib habit.

A key insight is that plotting is deferred. When you call ax.plot, Matplotlib does not immediately rasterize anything — it constructs Artist objects that describe what should be drawn and attaches them to the Axes. The actual rendering happens later, when show or savefig triggers the backend to walk the Artist tree.

This explains several behaviors: why you can keep modifying a plot after the plot call, why settings applied before show all take effect together, and why the same code can render differently depending on the backend.

The pipeline diagram traces the full path from code to output. Your Python call builds an Artist tree of Line2D, Text, and Patch objects. The backend then consumes that tree and rasterizes or vectorizes it. The final output is pixels (PNG) or vectors (SVG, PDF) depending on which backend ran.

Seeing it as a pipeline clarifies where each kind of problem lives: a missing label is an Artist-tree issue, while a blurry export or wrong file format is a backend issue.

A backend is the component that turns the abstract Artist tree into something concrete. The default Agg backend produces high-quality raster PNGs and is what runs when you savefig to an image. Interactive backends draw to a GUI window so you can pan and zoom. SVG and PDF backends emit vector graphics that scale without pixelation.

The elegant part is decoupling: the same plotting code targets any backend. You write the chart once and choose at render time whether it becomes a screen window, a PNG, or a vector PDF for print.

Here we connect the architecture back to Seaborn. A Seaborn function creates Matplotlib Figures and Axes, plots onto them, applies a chosen style and color palette, and then returns the objects. That return value is your hook back into raw Matplotlib.

So the workflow is: call Seaborn to get a good chart fast, then grab the returned Axes and continue editing with Matplotlib methods — set limits, add annotations, adjust the title. Nothing about Seaborn locks you out of the underlying engine.

This code slide proves the previous point concretely. sns.scatterplot returns a normal Matplotlib Axes, captured here as ax. The very next lines call standard Matplotlib methods on it — set_title, set_xlim — and plt.tight_layout to fix spacing. There is no special Seaborn-only ritual; you're back in plain Matplotlib the moment the Seaborn call returns.

This is the practical mechanism behind 'use both together' from the concept post.

Seaborn functions come in two flavors, and knowing which you're using prevents surprises. Axes-level functions like scatterplot, boxplot, and histplot draw onto a single Axes and return that Axes, so they slot neatly into your own subplot grids. Figure-level functions like relplot, catplot, and displot take over the whole Figure to build faceted grids for you, and they return a FacetGrid, not an Axes.

The common confusion is trying to place a figure-level plot inside an existing subplot — it won't cooperate, because it wants to own the Figure. Match the function level to whether you need one panel or a managed grid.

These tips distill the post into a debugging toolkit. Remember the hierarchy: Figure holds Axes holds Artists. Prefer explicit fig, ax = plt.subplots(). Know that plt.* targets the 'current' Axes. Remember the backend decides output format. And remember Seaborn hands you Axes you can keep tweaking.

With these five facts, almost any 'why is my plot doing that' question resolves to a clear answer about which object or layer is responsible.

This closes the mechanics post and points to the hands-on build. You now understand the model; the next post is pure practice — runnable code that constructs real charts in both libraries, step by step, so the concepts become muscle memory.