-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decision: Could .X = None? #464
Comments
Some additional contextThis has come up previously in #330. It seems that at some point this may have worked, but it's not covered in many tests. WhyIf As mentioned by @rcannood (#463 (comment)), you could leave I think this could be a nice way to structure the output of operations when result = AnnData(
obs=input.obs[[]], # Just the index
var = input.var[[]],
obsp={"distances": distances, "connectivities": connectivities},
uns={"neighbors": metadata}
)
if inplace:
input.update(result)
else:
return result Why notI think most code assumes that My main worry is that this touches the Current statusWhat currently worksYou can currently instantiate an a = AnnData(shape=(10, 20)) This can be read and written. For What doesn'tCopying and While it turns out we do have some tests around this case, we don't have much. I think we should be able to parameterize existing tests around this though. Miscellaneous thoughts
|
I’m in favor. I agree that since X is just the default layer, that means that the list of layers should also be able to be empty. For # utils.py
class Empty(Enum):
token = auto()
# _core/raw.py
def __init__(
self,
...
X: Union[np.ndarray, sparse.spmatrix, None, Empty] = Empty.token,
...
): ... Regarding initializers: I think it’s really hard to write them well, as you can’t depend on most things being there yet, so most assumptions in methods are broken, and one needs to be clever, arrange things carefully, and probably still repeat some code. The only fix I can come up with is “composition instead of inheritance”: Break an object down into independent parts which are created individually and then combined. Python isn’t the ideal language for it. |
Unless we actually store
Isn't
I think we also have an issue of handling too many cases in one function right now. I think it would be reasonable to split out |
Another argument for |
There has also been broad agreement with this on slack (@rcannood did you want to be invited to that btw?). I'd be happy with aiming for this in @rcannood, how much of this were you interested in helping with? Of the top of my head, these are the features we'll need check:
It's a long list, but I'm being granular. These should each be quite small tasks. Ideally many of these can be covered by a refactor of the tests. |
@LuckyMD I would be thrilled if GEO started having some standards for reporting beyond data being in SRA. |
I can take a crack at it, as long as it's reviewed by a core anndata developer :) I already have small changes in #463. Do you want to create a separate |
That sounds great!
I was thinking this should be split into multiple PRs, since many of these are orthogonal. Plus it's much easier to review and merge small PRs. Let's keep that PR's scope to just fixing up the I'm gonna mark this as resolved and start tracking what needs to be done in #467 |
Originally posted by @rcannood in #463 (comment)
The text was updated successfully, but these errors were encountered: