issue_comments: 612050871
This data as json
html_url | issue_url | id | node_id | user | created_at | updated_at | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
https://github.com/pydata/xarray/issues/3959#issuecomment-612050871 | https://api.github.com/repos/pydata/xarray/issues/3959 | 612050871 | MDEyOklzc3VlQ29tbWVudDYxMjA1MDg3MQ== | 6130352 | 2020-04-10T14:23:20Z | 2020-04-10T14:24:35Z | NONE | Thanks @keewis, that would work though I think it leads to an awkward result if I'm understanding correctly. Here's what I'm imagining: ```python from genetics import api These are different types of data structures I originally wanted to model as classesds1 = api.create_genotype_call_dataset(...) ds2 = api.create_genotype_probability_dataset(...) ds3 = api.create_haplotype_call_dataset(...) ds1, ds2, and ds3 are now just xr.Dataset instancesFor each of these different types of datasets I have separate accessorsthat expose dataset-type-specific analytical methods:@xr.register_dataset_accessor("genotype_calls") class GenotypeCallAccessor: def init(self, ds): self.ds = ds
@xr.register_dataset_accessor("genotype_probabilities") class GenotypeProbabilityAccessor: ??? # This also has some "analyze" method @xr.register_dataset_accessor("haplotype_calls") class HaplotypeCallAccessor: ??? # This also has some "analyze" method * Now, how do I prevent this? ***ds1.haplotype_calls.analyze() ds1 is really genotype call data so it shouldn't be possible to do a haplotype analysis on it``` Is there a way to make accessors available on an xr.Dataset based on some conditions about the dataset itself? That still seems like a bad solution, but I think it would help me here. I was trying to think of some way to use static structural subtyping but I don't see how that could ever work with accessors given that 1) they're attached at runtime and 2) all accessors are available on ALL Dataset instances, regardless of whether or not I know only certain things should be possible based on their content. If accessors are the only way Xarray plans to facilitate extension, has anyone managed to enable static type analysis on their extensions? In my case, I'd be happy to have any kind of safety whether its static or monkey-patched in at runtime, but I'm curious if making static analysis impossible was a part of the discussion in deciding on accessors. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
597475005 |