Remove instant selectors

[richardjgowers]

Another issue from the dev meetings, @orbeckst proposed removing these selectors

I'll try and summarise the currently available operations and what they do, along with the best alternative

u = mda.Universe()

# AtomGroup
# attribute based
u.atoms.H
u.atoms.select_atoms('name H')
# getitem based
u.atoms['H']
u.atoms.select_atoms('name H')

# ResidueGroup
rg = u.residues
rg.LYS
rg[rg.resname == 'LYS']

# Segment
u.segments[0].r1  # gives first residue
u.segments[0].residues[0]

# Universe
u.SYSTEM  # based on segids in topology
u.segments[u.segments.segids == 'SYSTEM']

They're also a little weird in that they *usually return Groups, but sometimes return singular objects if only one object was found. Ie RG.LYS will return a ResidueGroup unless there's only one LYS, in which case you get a Residue

Should we ditch (all of?) these?

[richardjgowers]

I don't like the __getattr__ hack versions, these are weird (in terms of other packages don't do similar hacks?) and are also annoying to program around. Attribute access should be for topology items and methods.

Having looked at the __getitem__ versions though, I do sort of like these. Slicing implies selection, so why not have slicing with a string lead to a selection being made? I think there's also precedent with packages like Pandas taking advantages of this.

I would even go a little further and say, why not make __getitem__ also alias to select_atoms, ie AtomGroup['resname LYS'] == AtomGroup.select_atoms('resname LYS'). This is a little messy if we keep the existing getitem shortcuts as we have to determine what type of string we've been passed.

tl;dr

1. ditch u.atoms.H u.s4AKE et al
2. keep u.atoms['H']
3. extend to u.residues['LYS']?
4. add u.atoms['around 2.0 protein'] ?
5. if __getitem__ == select_atoms, maybe ditch 2) & 3)

[kain88-de]

if getitem == select_atoms, maybe ditch 2) & 3)

I like this

[mnmelo]

+1 for 1. and 5.
I also dislike __getattr__ because it can make for cryptic bugs instead of plain AttributeErrors. But I recall @orbeckst was keen on keeping the quick accessors. Change of mind?

[orbeckst]

I think it's really not used very much any more and with tab-completion in modern UIs it really doesn't matter so much any more, either. And if we want to slim down then it's now or not any time soon. Getting rid of stuff also seems to make devs happy ;-).

…

On 2 Jun, 2017, at 18:04, mnmelo ***@***.***> wrote: But I recall @orbeckstwas keen on keeping the quick accessors. Change of mind?

-- Oliver Beckstein * [email protected] skype: orbeckst * [email protected]

[orbeckst]

I would really just ditch everything (i.e., 1); I wouldn't bother with __getitem__ access, just do selections via selection strings (or boolean selections/slicing). If, over time, we find that we need to improve how we do selections or want to look more like pandas then we can re-introduce something. But initially I'd start with something simpler.

(I admit that there's a certain logic to atoms["atomname"] and residues["resname"] and segments["segname"] but it seems like an another exception that you have to teach to users. Maybe leave it sit for a while to see how it feels after simplifying the system.)

[orbeckst]

Totally random comment: should we shorten group.select_atoms() to group.select()? There is no select_residues (and I don't want one either) so it seems very superfluous to have "atoms" in the name.

[orbeckst]

@MDAnalysis/coredevs we need a few more opinions here on how to proceed. Take your picks 1 ... 5.

[richardjgowers]

@orbeckst ResidueGroup.select() is a little ambiguous as to what it selects, RG.select_atoms makes it clear you'll get atoms not residues.

I can raise a new issue for __getitem__ == select_atoms, in which case we can ditch all the fancy shortcuts above.

[jbarnoud]

+1 for 1. Why not 5, but it does not bring much except maybe confusion; now we can say that AG can be indexed like a numpy array, with the select string in __getitem__ we have to add a caveat.

select_atoms is much more explicit than select.

[orbeckst]

@jbarnoud has a good point regarding how we explain slicing of groups: being able to say "just like numpy arrays" is simple and easily understood.

Let's go with 1 (remove it all).

(The majority is also in favor of keeping select_atoms() so no changes there.)

[kain88-de]

We should also ditch option 2 then.

[orbeckst]

We should also ditch option 2 then.

Yes!

[IAlibay]

@richardjgowers this is next up on the removal list for v1.0, unless there is still work to be done here, are you ok with me giving it a go at doing the necessary removals?

[richardjgowers]