Figure: Refactor how plotting methods are attached to the Figure class#4612
Open
Figure: Refactor how plotting methods are attached to the Figure class#4612
Conversation
Member
Author
|
This PR is backward-compatible, but it's a big low-level refactor. Ping @GenericMappingTools/pygmt-maintainers for reviews. Edit: Previously, it was possible to do |
Member
Author
|
This PR also renames the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
In PR #3849, we're seeing many static type check errors (https://github.com/GenericMappingTools/pygmt/actions/runs/25118862756/job/73613589767?pr=3849), mainly because in
pygmtlogo, we're trying to re-import theFigureclass, which causes some circular imports.Codex recommends a different way to attach the plotting wrappers to the
Figureclass, which can solve the static type error found in PR #3849. Changes in this PR are made by Codex.Summary
This PR refactors how plotting methods are attached to
pygmt.Figureand clarifies the role ofpygmt.src.Why
Previously,
Figuremethods were attached through a class-scopedfrom pygmt.src import (...)block inpygmt/figure.py. That worked at runtime, but it had a few drawbacks:pygmt/src/__init__.pyjust to populateFigure.FigureWhat changed
pygmt/figure.pypygmt.src.*module.Figureclass body, e.g.plot = _plot.pygmt/src/__init__.pyFigure-bound plotting methods frompygmt.src.Figuremethods.Why this is better
This makes the API structure clearer:
pygmt.srcbecomes a cleaner namespace for standalone operations.Figureis the clear home for plotting methods.It also improves maintainability:
Figuremethod points to one explicit source module.Figureno longer depends on package-level re-export behavior for method attachment.Behavioral intent
This is intended as an internal API-structure cleanup, not a plotting behavior change. The plotting implementations themselves are unchanged; only the way they are attached/exported has been reorganized.