Skip to content

Converting mpl_style.py to a static stylesheet ? #16053

Open

Description

@neutrinoceros

I noticed that astropy/visualization/mpl_style.py would work as as static matplotlib stylesheet, which matplotlib has functionality to utilise even without importing astropy since version 3.7.0.

Now, there's a comment in there indicating that the module isn't recommended since astropy 3.0

# plotting style. It is no longer documented/recommended as of Astropy v3.0
(authored by @astrofrog), but it's kept for backward compatibility. Is there any appetite to actually "promote" it to a static stylesheet (this can absolutely be done in a backward-compatible way), or should this module just be left alone ?

My two cents on this: it'd be nice to lean on matplotlib's new function, but it will probably be easiest when support for matplotlib<3.7 is dropped, which, following SPEC 0, could happen in early 2025.

Activity

  1. neutrinoceros commented on Feb 16, 2024

    @neutrinoceros
    ContributorAuthor

    and to answer a question I had while researching this: yes, even the color cycle can be defined "statically" (as in, leaving the dynamic part of instantiating cycler.cycler to matplotlib)

  2. astrofrog commented on Feb 16, 2024

    @astrofrog
    Member

    That style was considered to be inferior to the current Matplotlib defaults so there is no point in reviving it. It might be worth finally deprecating and removing it though.

  3. added
    API changePRs and issues that change an existing API, possibly requiring a deprecation period
    on Feb 16, 2024
  4. neutrinoceros commented on Feb 17, 2024

    @neutrinoceros
    ContributorAuthor

    It is still used in documentation examples. Should they be updated just use mpl's default style ?

  5. hamogu commented on Mar 1, 2024

    @hamogu
    Member

    I'd be in favor of using matplotlibs defaults for simplicity. But, if I remember correctly, some people felt strongly about having astropy-orange in some plot etc. That's (I think) why this was left alone at the time - there are better places to spend our effort.
    However, I agree with @astrofrog : It might be time to finally get rid of it altogether.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    API changePRs and issues that change an existing API, possibly requiring a deprecation periodvisualization

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions