bug fix: hue in sc.pl.violin
closses #1174
hue key is now added to keys if hue is in kwds. before obs_tidy did not include this keyword, so this resulted in an ValueError
an alternative would be to add hue as a function parameter to sc.pl.violin
Codecov Report
Merging #1822 (62e48bc) into master (c488909) will increase coverage by
0.01%. The diff coverage is50.00%.
@@ Coverage Diff @@
## master #1822 +/- ##
==========================================
+ Coverage 71.18% 71.20% +0.01%
==========================================
Files 92 92
Lines 11190 11192 +2
==========================================
+ Hits 7966 7969 +3
+ Misses 3224 3223 -1
| Impacted Files | Coverage Δ | |
|---|---|---|
| scanpy/plotting/_anndata.py | 84.39% <50.00%> (-0.08%) |
:arrow_down: |
| scanpy/logging.py | 98.38% <0.00%> (+1.61%) |
:arrow_up: |
Thanks for the PR.
I think if this is added it should be added as a function parameter. It should also get some tests, I'm a bit concerned how just passing hue will work with the groupby and palette parameters.
would it then make generally sense to add an optional hue parameter in seaborn based plotting functions? was checking if hue is anywhere used but does not seem to be the case.
will check behaviour for this wrt groupby and palette.
would it then make generally sense to add an optional hue parameter in seaborn based plotting functions? was checking if hue is anywhere used but does not seem to be the case.
I'm not sure. I don't know off the top of my head how well we can make current functions work with hue, since seaborn uses it to group observations in many cases.
Looking at this again, my current reading is that
sc.pl.violin(adata, keys=keys, groupby=groupby, hue=hue)
should translate into something like:
df = sc.get.obs_df(adata, [groupby, hue] + keys)
for k in keys:
sns.violinplot(data=df, x=groupby, y=k, hue=hue)
sns.catplot could also be a good model, but I don't think it supports the same range of attributes.
While also passing through the right color palette to use for hue.
- We would need to address where the legend goes, since I believe this would currently repeat the same legend for each plot
-
palettehandling, which I believe is currently resulting in aKeyError - Axis labeling, we would probably want it per groupby, and leave
hueto the legend.