Skip to content

MNT: Remove AxesStack and deprecated behavior of reuse of existing axes with same arguments #18832

Closed

Description

@lpsinger

Describe the issue

Summary

In Matplotlib 2.1, the behavior of reusing existing axes when created with the same arguments was deprecated (see #9037). The request is to finally remove this behavior.

My immediate motivation is that I have a collection of projection classes that take as a keyword argument an instance of astropy.coordinates.SkyCoord, which as of Astropy 4.1 are no longer hashable (see also astropy/astropy#9857). This unexpectedly broke my code because I had not realized that projection keyword arguments had to be hashable.

Proposed fix

Remove the AxesStack class, remove the Figure._make_key method, and update the documentation to reflect the removal of the old deprecated behavior.

Activity

  1. added this to the v3.4.0 milestone on Oct 28, 2020
  2. tacaswell commented on Oct 28, 2020

    @tacaswell
    Member

    @anntzer do you already have a branch for this?

  3. anntzer commented on Oct 28, 2020

    @anntzer
    Contributor

    IIRC I kind of gave up on that due to unclearness of what we want to keep supporting, e.g. wrt. gca(projection=..., ...) (#10700) (which goes through the same AxesStack info). Probably you need to make some executive decisions on that :)

  4. lpsinger commented on Nov 1, 2020

    @lpsinger
    ContributorAuthor

    @anntzer, after studying #10700, my suggestion is:

    1. In the next release of Matplotlib:
      • Deprecate kwargs for gca()
      • Remove projection kwargs lookup (for gca() and also subplots(), etc.)
      • If gca() is called without kwargs, simply return the current axes
      • If gca() kwargs matches the kwargs of the current axes, return those axes, otherwise raise an exception
    2. In a future release of Matplotlib:
      • Remove kwargs entirely from gca()

    What do you think?

  5. anntzer commented on Nov 1, 2020

    @anntzer
    Contributor

    I am personally fine with fully deprecating all kwargs to gca(), but there was some pushback wrt. subplot() in #12513 (and IIRC these basically go through the same machinery) and I had little interest in fighting that fight, which is why I decided to let @tacaswell decide :)

  6. lpsinger commented on Nov 8, 2020

    @lpsinger
    ContributorAuthor

    @tacaswell, what do you think? I am happy to take a stab at the above changes, if you agree with the approach.

  7. lpsinger commented on Nov 18, 2020

    @lpsinger
    ContributorAuthor

    How do we want to handle a call to gca() without kwargs when there are not yet any axes? Return None? Or return a new axes?

  8. anntzer commented on Nov 18, 2020

    @anntzer
    Contributor

    That should definitely return a new axes (I'd guess that's an extremely common use case (like it or not)).

  9. added 6 commits that reference this issue on Nov 19, 2020
    248c960
    dd1a18c
    23b1310
    7be0c7a
    0f59282
    8540c04
  10. added a commit that references this issue on Dec 6, 2020
    2d5e345
  11. added 4 commits that reference this issue on Dec 19, 2020
    6a8bf81
    a886c4e
    bcee8ab
    e6df62e
  12. added 2 commits that reference this issue on Jan 7, 2021
    f0ca259
    400aa25
  13. added 5 commits that reference this issue on Jan 19, 2021
    598f7fa
    78d231f
    0db9c6c
    2377702
    68498c6
  14. added a commit that references this issue on Feb 19, 2021
  15. added a commit that references this issue on Mar 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions