why not plt.clf() instead?

also, this is in a loop over systems (starting line 139) -- as I understand, this creates a new axis every time (unclear to me if the old one remains in existence). Why I try this:

>>> g = control.tf(1,[1,1])
>>> h = control.tf(1,[1,2])
>>> _ = control.bode_plot([g, h])
>>> plt.show()

I see only the frequency response of h.

plt.clf(): the default behavior for matplotlib is that if you call plot twice, you get the new data on top of the previous data. bode is supposed to emulate that => this PR implements that behavior.

For the example with a list of TFs: this is the incorrect behavior, but need to look into it. Could be that we need to pass a tuple? (Can't check right now.)

If I run this:

#!/usr/bin/env python3

import matplotlib.pyplot as plt
import control

g = control.tf(1,[1,1])
h = 1 - g

control.bode_plot(g)
control.bode_plot(h)

plt.show()

on your branch, I see only h.

My understanding from the docs is that different labels will result in different axes being created; from that link:

The axes label attribute has been exposed for this purpose: if you want two axes that are otherwise identical to be added to the figure, make sure you give them unique labels

I didn't realize you were aiming to emulate Matplotlib's behaviour; this is reasonable, but seems like it will require some way to check if there are existing Bode plot axes. If Matplotlib has the equivalent of Matlab's "findobj", it should be doable: search the current figure for axes with labels "pycontrol-bode-mag", and "[...]-phase", and re-use them if they exist; if they don't, create them.

this seems to work:

diff --git a/control/freqplot.py b/control/freqplot.py
index c53e83f..368bdfc 100644
--- a/control/freqplot.py
+++ b/control/freqplot.py
@@ -135,6 +135,20 @@ def bode_plot(syslist, omega=None, dB=None, Hz=None, deg=None,
             else:
                 omega = sp.logspace(np.log10(omega_limits[0]), np.log10(omega_limits[1]), endpoint=True)
 
+    if Plot:
+        fig = plt.gcf()
+        ax_mag = None
+        ax_phase = None
+        for ax in fig.axes:
+            if ax.get_label() == 'pycontrol-bode-mag':
+                ax_mag = ax
+            elif ax.get_label() == 'pycontrol-bode-phs':
+                ax_phase = ax
+        if ax_mag is None or ax_phase is None:
+            plt.clf()
+            ax_mag = plt.subplot(211, label = 'pycontrol-bode-mag')
+            ax_phase = plt.subplot(212, label = 'pycontrol-bode-phs', sharex=ax_mag)
+
     mags, phases, omegas, nyquistfrqs = [], [], [], []
     for sys in syslist:
         if (sys.inputs > 1 or sys.outputs > 1):
@@ -172,7 +186,6 @@ def bode_plot(syslist, omega=None, dB=None, Hz=None, deg=None,
 
             if (Plot):
                 # Magnitude plot
-                ax_mag = plt.subplot(211);
                 if dB:
                     pltline = ax_mag.semilogx(omega_plot, 20 * np.log10(mag), *args, **kwargs)
                 else:
@@ -186,7 +199,6 @@ def bode_plot(syslist, omega=None, dB=None, Hz=None, deg=None,
                 ax_mag.set_ylabel("Magnitude (dB)" if dB else "Magnitude")
 
                 # Phase plot
-                ax_phase = plt.subplot(212, sharex=ax_mag);
                 if deg:
                     phase_plot = phase * 180. / math.pi
                 else:

I've extended the above to the gang-of-four plots too: https://github.com/roryyorke/python-control/tree/rory/mplib-ax-warnings-2 ; this covers all of the subplot() calls in control/. Successive calls to bode_plot and gangof4_plot will add to the existing axes, as desired.

However, this breaks examples/pvtol-nested.py, specifically, figure 6, which uses subplot(211) and subplot(212) to add annotations to the gain and phase plots. This example will eventually break when Matplotlib changes subplot() as warned in the deprecation we're looking at. (When running that example, Matplotlib warns that matplotlib.pyplot.hold() is going to disappear at some point too.)

I think to keep python-control working with the new Matplotlib way, we'll have to overhaul the plotting a bit; we should allow the user to get hold of the line objects (for creating legends), and to the axes (for adding lines, points, text, ...). All of this is quite a bit of work, so perhaps we should leave it to after 0.8.0.

Separately, it might be good to add run the examples as part of Travis CI; and perhaps we should turn deprecation warnings into errors in all Travis CI runs.