mdanalysis
mdanalysis copied to clipboard
MDAnalysis
3.0 release of MDAnalysis
This is the meta issue for the 3.0 release of MDAnalysis.
The target date will be a year from the ideal release date of v2.3.0 (which we will release early): 2nd September 2023.
This will allow for four minor versions (v2.3.0 inclusive) to be released before v3.0.
The 3.0 release will be API breaking, so please discuss what needs doing here and add any relevant issues to the milestone tracker.
So something that might be worth breaking for v3.0 is resid/icode handling, see: #2308
I think that:
- removing resnums (not resids, we also have a thing called resnum for some reason...)
- mashing resid and icode together into some magic object (see below)
Icodes are easy to forget, but important for ordering. I think maybe having resids and icodes combined into one object would help people work with these. Something as simple as a (quasi-) namedtuple(resid, icode) that just works for selection, sorting etc would be a nice QOL improvement.
There's also some improvements we could make to residue recognition that we've been hesitant to make as it would be breaking other behaviour, see #3659
I think something I've got wrong historically is the difference between segments and chainIDs. Currently chainID is an atom attribute, but really it should alias to segid (unless I'm still wrong?)
I think something I've got wrong historically is the difference between segments and chainIDs. Currently chainID is an atom attribute, but really it should alias to segid (unless I'm still wrong?)
It's a bit more complicated than that I believe. If I remember correctly, segment is a holdover of charmm things, i.e. there is no such thing as a segid in a pdbv3 compliant file
Sure so charmm segments == PDB chains? This would be a good breaking change to make.
@richardjgowers I'm pretty sure there's an issue about this somewhere already. Because they are technically different fields on read you can't just equate them. honestly I'd just remove any reliance on segids
Also how we handle units. Currently we assume everything is A, but this isn't explicit enough and we could also toggle nm somehow too. I'm not sure having non-numpy arrays is the solution here (they're clunky) but definitely having some attribute on a Universe stating its units for each attribute would be nice
Also how we handle units. Currently we assume everything is A, but this isn't explicit enough and we could also toggle nm somehow too. I'm not sure having non-numpy arrays is the solution here (they're clunky) but definitely having some attribute on a Universe stating its units for each attribute would be nice
I had an initial crack at some of this in #3941. Long term vision for this was to have .results.quantified attr return a pint quantified array.
