Skip to content

Deprecate "hold" kwarg and machinery. #7516

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Nov 27, 2016

Conversation

efiring
Copy link
Member

@efiring efiring commented Nov 26, 2016

This follows #7515 and addresses #3070.

@efiring efiring added this to the 2.0 (style change major release) milestone Nov 26, 2016
@efiring efiring force-pushed the kill_hold_stage2 branch 2 times, most recently from 65a10b9 to 5e955a2 Compare November 26, 2016 03:23
"""return the HOLD status of the axes

The `hold` mechanism is deprecated and will be removed in
v3.0.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we not commit to a specific version here? Or at least make it one of 2.2, 2.3 or 2.4, which should be far away enough... Same comments below.

(mpl 3.0 sounds a bit like python 4 to me)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is the correct version if we wish to follow SemVer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... which we haven't been doing so far?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was not fully concluded in #3070.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would just say "in a future feature release" (as opposed to "bugfix release") in that case.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought this would generate some controversy... I would like to see "hold" go away ASAP, and I don't have strong opinions about version numbering. It seemed like the discussion in #3070 was leaning in the direction of going wild with major version numbers--why not, Firefox is up to 50.0! Seriously, regardless of how the numbering controversy is resolved, we need to find a way to get releases out more frequently.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will at least have a 3.0 when we drop python2 support (so 2018).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should be following SemVer, and we certainly are with 2.0. Therefore, when we remove hold it will be ++major_version. Is there any reason this wouldn't make 3.0?

@@ -1730,7 +1732,7 @@ def xcorr(self, x, y, normed=True, detrend=mlab.detrend_none,

y : sequence of scalars of length n

hold : boolean, optional, default: True
hold : boolean, optional, *deprecated*, default: True
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "correct" way to document deprecation with numpydoc is through the deprecation notes section, but I don't think this matters much.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This puts it out front, so I will consider it at least good enough for now.

Copy link
Member

@NelleV NelleV left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall it looks good, but I think you missed one deprecation warning.

@@ -2486,24 +2499,26 @@ def getname_val(identifier):
def _autogen_docstring(base):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't that function become obselete? The only thing it did is append the kwarg information on hold.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is also handling the dedenting of the docstring from the Axes method, and adding a couple linefeeds. That is why I left it in.

addendum = docstring.Appender(msg, '\n\n')
return lambda func: addendum(docstring.copy_dedent(base)(func))

# This function cannot be generated by boilerplate.py because it may
# return an image or a line.
@_autogen_docstring(Axes.spy)
def spy(Z, precision=0, marker=None, markersize=None, aspect='equal', hold=None, **kwargs):
def spy(Z, precision=0, marker=None, markersize=None, aspect='equal', **kwargs):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think hold needs to be explicitly deprecated here as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. A fix is on the way.

Copy link
Member

@tacaswell tacaswell Nov 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only place that hold in removed a positional argument. I am mildly 👎 on breaking that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I lost track of what file I was in (thought that was in _axes.py not pyplot.py. Still not enthusiastic about this change, at +0

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spy is an obscure and peculiar function; 'hold' was the 6th argument, with only the first being in the signature as a purely positional argument. Although technically 'hold' could be used as a positional argument here in someone's code, I think the risk of serious damage from this change is minuscule, and worth taking for the sake of simplicity and consistency: keeping "hold" out of all function signatures.

ax.hold(hold)
ax._hold = hold
from matplotlib.cbook import mplDeprecation
warnings.warn("The 'hold' kwarg is deprecated since 2.0.",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be very nitpicky, the hold argument here is not a kwarg. (OK, no one cares…)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hold is a keyword argument; are you asking me to spell that out, as opposed to using the common abbreviation? I don't mind doing that, I just want to be clear about what the nit is.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you should bother with that comment :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I spelled it out.

@@ -145,6 +145,13 @@ def validate_bool_maybe_none(b):
raise ValueError('Could not convert "%s" to boolean' % b)


def deprecate_axes_hold(value):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you make this function private? It's unlikely that anyone is every going to use it, but who knows…

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could, but I was just following the pattern in rcsetup.py, which has several special-purpose functions like this. I think that it is OK to credit other programmers with enough common sense to realize that a function like this will go away when it is no longer needed. We might do more harm than good by trying to be too strict about leading underscores.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As long as it is very clear to all matplotlib developer that this function will disappear along with hold, that's OK with me, thought I'd rather have it private. Explicit is always better than implicit.

@efiring
Copy link
Member Author

efiring commented Nov 26, 2016 via email

@NelleV
Copy link
Member

NelleV commented Nov 26, 2016

Once you think this is ready to be merged, can you ping us on it or add the [MRG] tag to the PR?

@efiring efiring changed the title Deprecate "hold" kwarg and machinery. [MRG] Deprecate "hold" kwarg and machinery. Nov 27, 2016
@efiring
Copy link
Member Author

efiring commented Nov 27, 2016

I think this is in reasonable shape now. The messages specifying 3.0 as the removal point are subject to debate; but if the decision is to phrase them differently, that change could be a separate tiny PR.

To make the deprecation strategy explicit:

  • This is stage one: if anyone tries to set a "hold" value, it will trigger a warning; otherwise, there should be no change in the behavior.
  • The next stage could be to change all the warnings to exceptions, enabling the removal of part, but not all, of the "hold" system. I view this as an optional stage, not an essential one. I would prefer to skip it.
  • The final stage is gleefully deleting every last vestige of the "hold" machinery.

Basemap needs to be treated in sync with mpl, but it can be done in a simpler fashion. I will submit a PR for that now.

The behavior will remain consistent with the default ``hold=True``
state that has long been in place. Instead of using a function
or keyword argument (``hold=False``) to change that behavior,
explicitly clear the axes or figure as needed prior to subsequent
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe link these two things?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I don't understand what you are suggesting.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A cross-reference to the relevant functions for clearing the Axes/Figure.

%(ax)s._hold = hold
from matplotlib.cbook import mplDeprecation
warnings.warn("The 'hold' keyword argument is deprecated since 2.0.",
mplDeprecation)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use stacklevel=2, so that the warning references the caller instead of pyplot.py?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried that just now, but it gives puzzling result when using pyplot commands from the command line, or from a function defined on the command line. I think we are better off leaving the default in place.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, really?

>>> import numpy as np
>>> import matplotlib.pyplot as plt
>>> plt.plot(np.arange(10), hold=False)
/home/elliott/code/matplotlib/lib/matplotlib/pyplot.py:3315: MatplotlibDeprecationWarning: The 'hold' keyword argument is deprecated since 2.0.
  mplDeprecation)
[<matplotlib.lines.Line2D object at 0x7f3722d1f320>]

vs.

>>> import numpy as np
>>> import matplotlib.pyplot as plt
>>> plt.plot(np.arange(10), hold=False)
__main__:1: MatplotlibDeprecationWarning: The 'hold' keyword argument is deprecated since 2.0.
[<matplotlib.lines.Line2D object at 0x7f83598b5c50>]

looks correct to me.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is with ipython and stacklevel=2:

In [1]: plot([1,2,3], hold=True)
/Users/efiring/anaconda/envs/test/bin/ipython:1: MatplotlibDeprecationWarning: The 'hold' keyword argument is deprecated since 2.0.
  #!/bin/bash /Users/efiring/anaconda/envs/test/bin/python.app
[<matplotlib.lines.Line2D at 0x1151f1f98>]

In [2]: def make_warning():
   ...:     plot([1,2,3], hold=True)
   ...:

In [3]: make_warning()
/Users/efiring/anaconda/envs/test/bin/ipython:2: MatplotlibDeprecationWarning: The 'hold' keyword argument is deprecated since 2.0.
  if __name__ == '__main__':

and with the default:

In [1]: plot([1,2,3], hold=True)
/Users/efiring/work/programs/py/mpl/matplotlib/lib/matplotlib/pyplot.py:3315: MatplotlibDeprecationWarning: The 'hold' keyword argument is deprecated since 2.0.
  mplDeprecation)
[<matplotlib.lines.Line2D at 0x117dce0b8>]

In [2]: def make_warning():
    plot([1,2,3], hold=True)
   ...:

In [3]: make_warning()
/Users/efiring/work/programs/py/mpl/matplotlib/lib/matplotlib/pyplot.py:3315: MatplotlibDeprecationWarning: The 'hold' keyword argument is deprecated since 2.0.
  mplDeprecation)

For this use, the default looks better to me. What would really be needed for someone to debug a hold kwarg buried in a library is a full stack trace, but we are not going to put that in.

@NelleV NelleV changed the title [MRG] Deprecate "hold" kwarg and machinery. [MRG+1] Deprecate "hold" kwarg and machinery. Nov 27, 2016
@NelleV
Copy link
Member

NelleV commented Nov 27, 2016

Thanks for taking hold down, @efiring ! The patch looks good to me.

@tacaswell tacaswell merged commit 8251436 into matplotlib:v2.x Nov 27, 2016
@tacaswell
Copy link
Member

👍 merged and did the merge up to master

@efiring
Copy link
Member Author

efiring commented Nov 27, 2016 via email

@efiring efiring deleted the kill_hold_stage2 branch November 27, 2016 19:36
@QuLogic QuLogic changed the title [MRG+1] Deprecate "hold" kwarg and machinery. Deprecate "hold" kwarg and machinery. Nov 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants