Why not do it as a decorator rather than simply removing it? Simplifies a
lot of logic that way.

On Sat, May 17, 2014 at 10:28 AM, Thomas A Caswell <notifications@github.com

wrote:

Push all hold logic up to the pyplot layer.

Assume that if client code wants to clear the axes, they will call it them
selves.

Tagged an v2.0 as I see no way to do this in a reverse compatible way.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3070
.

I spoke with @mdboom and @efiring about this and there seems to be consensus to remove the hold logic from the library (both Axes and pyplot)

Rough plan:

• 2.1 raise warnings if hold is False
• 2.2 raise exception if hold is False
• 2.3 remove args/kwargs for hold

[edited]

I am unclear of what, exactly, the plan is. Is hold going to be removed entirely, or only from axes? If the latter, is the default hold state going to be changed to True in pyplot? At what stage is the hold method going to be removed from Axes?

Ah, sorry this is unclear. This issue started as one thing and then morphed into another!

The plan is to remove it from the library entirely,

there seems to be consensus to remove the hold logic from the library

👍

Rough plan: ... 2.3 remove args/kwargs for hold

How can we call that a minor version change, it is an API breakage. Is there a reason not to call it 3.0?

I seriously question whether anybody uses this "feature". I have always
considered it a bug in Matlab.

On Wed, Sep 16, 2015 at 9:20 AM, Phil Elson notifications@github.com
wrote:

there seems to be consensus to remove the hold logic from the library

[image: 👍]

Rough plan: ... 2.3 remove args/kwargs for hold

How can we call that a minor version change, it is an API breakage. Is
there a reason not to call it 3.0?

—
Reply to this email directly or view it on GitHub
#3070 (comment)
.

On 2015/09/16 3:20 AM, Phil Elson wrote:

How can we call that a minor version change, it is an API breakage. Is
there a reason not to call it 3.0?

It has been standard practice for deprecation/removal cycles to occur
with changes at the decimal level.

It has been standard practice for deprecation/removal cycles to occur
with changes at the decimal level.

I appreciate that, but should we want to be using a well defined version scheme, Semver would be the natural choice. Without it, you cannot reliably expect to update matplotlib between "minor" versions without expecting API breakage.

On 2015/09/16 3:20 AM, Phil Elson wrote:

Rough plan: ... 2.3 remove args/kwargs for hold

How can we call that a minor version change, it is an API breakage. Is
there a reason not to call it 3.0?

Isn't the 2.2 stage (Exception if hold is True) also an API breakage?

Isn't the 2.2 stage (Exception if hold is True) also an API breakage?

Indeed. That would be the point at which I would call a new major version. Ideally the exception type would be the same as the if we hadn't left a helpful hint as to the API change.

I am 👍 on being more liberal with major versions.

I'm not opposed. It's probably a good idea. I think there will still be shades of grey, though.

Is that still something we'd like to address before 2.0?

I may have a PR for this tomorrow, can we re-evaluate then?

Sounds like a plan!

closed by #7515 and #7516.

I am using the hold command all the time and wondering now with which sequence of commands I could replace it? Use case: I want to make a new (different) plot but in the same figure window. How should I proceed?

EDIT: it seems that the figures clear command works in this scenario. It might be worth while accompanying the depreciation warning with suggestions how to possibly replace the functionality from the users perspective.

For anyone reading this and panicking (as I initially did), you can create custom subroutines in a library (or that are always loaded into python) that duplicate the functionality of hold for whatever plots you typically make (like "plot," "hist," "hist2d," etc). It's going to be obnoxious to have one plot (or hist) command for hold(True) and a second one for hold(False), but apparently we're removing Matlab analysis functionality for... reasons...

@drrelyea Sorry this is causing frustration to you.

How do you use hold? Are you only using it in the pyplot API or also using on in the OO api? If you are planning to have two versions (one which implicitly calls cla and one that does not) would
explicitly calling cla be an acceptable alternative?

Hi @tacaswell ,

I'm a data scientist, and I do a lot of basic analysis. When I'm banging away on new data, I don't see why I'd need to hit cla before I hit plot if I'm going to make 40 or 50 plots in a session, which is not atypical. They're all ad-hoc cases (or else I'd automate everything). This is why Matlab (which I no longer use) has "hold."

I can easily recreate the functionality, and if it's a bear to maintain for whatever reason, I don't hate you for removing it. However, it's one of the single most common commands I use in matplotlib, as turning it on and off on a dime is invaluable when racing through data.

Typical use case is ipython, pyplot API, though I use the OO API when automating (of course).

You obviously have a lot of data science usage, and I'd wager that the majority of them are in jupyter, but a good deal of them avoid that (it's really less flexible than I prefer). You also have a lot of people who've moved over from Matlab, but I'd also wager that most of them wind up in jupyter. I could be a one-off, and I don't know a good way of polling people (/r/python?) to figure this out. Your warning was good enough for me to panic and adjust, which I assume most people will. I just wrote this to make sure that people who panic will realize that adjusting isn't all that difficult.

I’ll say that I think analyzing data from the command line is very fragile and prone to loss of final results. I used matlab for over twenty years and pretty quickly switched to evaluating expressions from a source script. The “evaluate cell” (cmd enter) functionality in the editor is invaluable. Ie what I now get from Jupyter.

Interesting. I also do most of my personal ad-hoc analysis from IPython, but always end up with more than one open window with overlayed data sets. I also tend to end up always writing little helpers functions that given some data, do some processing, and then create and fill a figure complete with legends, axes labels, and multi-axes coordinated plots. There is always the risk of losing which figure is the 'active' figure, if you mess up with 'hold on', then you just have to remove a line. If you mess up with 'hold off' you have to remake what ever it was you just destroyed. On the other hand, I use plt.close('all') all the time 😈 .

You can do a custom wrapping of pyplot via

import types
from functools import wraps

def my_decorator(inp):
    @wraps(inp)
    def inner(*args, **kwargs):
        plt.cla()
        return inp(*args, **kwargs)
    
    return inner

holdoff_plt = types.SimpleNamespace(**{f: my_decorator(getattr(plt, f))
                                       for f in dir(plt)
                                       if isinstance(getattr(plt, f), types.FunctionType)})

You can put in what ever sort of logic you want in there, like a ring of 5 figures you cycle through etc.

from itertools import count
_p_count = count()

def my_decorator(func):
    @wraps(func)
    def inner(*args, **kwargs):
        fig = plt.figure(next(_p_count) % 5)
        fig.clf()
        return func(*args, **kwargs)
    return inner