scverse / scverse/spatialdata-plot

Feature request: remove need for intermediate pl calls when chaining renderers

Open
#54 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement priority: low
Dominant language
Python
Stars
86
Forks
21
Avg merge
14h 50m
Merged PRs (30d)
3

Description

Description of feature

Thanks for the super nice work, @timtreis and @sagar87 ! I think it would be nice if we didn't have to add intermediate calls to pl when chaining renderers. That is, I think it would be nice if instead of this:

sdata.pl.render_images().pl.render_shapes().pl.show()

We could do this:

sdata.pl.render_images().render_shapes().show()

This perhaps could be possible if the render_*() methods returned the plot accessor instead of the SpatialData object. I suppose this means that one couldn't do a pp operation after a pl operation, but maybe that suggests the pl and pp operations should be on the same level of the hierarchy or one should do their preprocessing first, then their plotting. I'm not sure what's best here, but it might be good to experiment with this once all of the p0 functionality is finished.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by inspecting the pl accessor and the render_* methods, especially how they currently return SpatialData and support chained calls. Compare the existing sdata.pl.render_images().pl.render_shapes().pl.show() example with the proposed chaining behavior, and resolve how pl and pp operations should interact. Done means a decided API design and working renderer chaining without intermediate pl calls.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
data-visualization
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.