Specs for all elements #554
Conversation
Used current `read_elem`, `write_elem` framework for h5ad files
Codecov Report
@@ Coverage Diff @@
## master #554 +/- ##
==========================================
- Coverage 83.41% 83.07% -0.34%
==========================================
Files 31 34 +3
Lines 4148 4349 +201
==========================================
+ Hits 3460 3613 +153
- Misses 688 736 +48
|
OldFormatWarning is raised when a file so old the elements don't have an encoding type is read in. A test was added to check than newly written files don't throw these.
|
We now have warnings for when an element is found that doesn't have a spec. These are not user visible, but we should silence them further for the tests. |
|
Forgot about the |
|
Huh, pretty sure I meant to call c0112fc something different. Like "start zarr support". Still needs some work. Like most backwards compat and figuring out what I can delete. |
* convert np.bool_ to bool so json module doesn't error * actually label `str` elements as strings * read strings back as `str` not `np.str_`
|
I think with #662, there’s no real way around |
|
Long term yes, but I think this can go through without it. I think designing that system is worth a bit more care, and we may be able to base that design (or at least get help with it) from a "single cell data interchange" schema (will hopefully hear more on that in January). The way around this is for now is basically just long encoding names. So |
This PR adds specs for each element of an anndata object. That is, on disk each element will be have attributes
"encoding-type"and"encoding-version". For more info see this issue #555TODO:
lists, we convert them to arrays. But we handle arrays differently based on the type of their values. All Most of this system is build aroundelement-type -> on-disk-format, but these types break this a little. Currently handling this by not settingencoding-type/encoding-versionif they're already set, so we can set them for the converted value.[ ] Tests for SparseDataset indexing (sometimes it wasn't returning aout of scopecsr_matrix[ ] Don't allow unlabelled elements in more recently written objectsMaybe this PR, maybe not:
I have decided: not
- [ ] Consolidate "modified" reading methods- [ ] Figure out what the scope is for an individual resolver- [ ] Partial IO? (probably not until during the 0.8.x release series)This might also be the right time to cut a 0.7 maintenance branch, and make master 0.8 specific.