Interchangeability of AtomGroup and selection strings

[GoogleCodeExporter]

Following the discussion on Issue 171 it would be interesting to adapt any 
functions that take AtomGroups to also be able to take selection strings (and 
vice versa).

I brought it up because an analysis class I use often, LeafletFinder, accepts 
exclusively selection strings. I have a fix for this particular case, and since 
I'm working on Issue 174 I'll look into allowing AtomGroups to be passed to 
selection functions.

Original issue reported on code.google.com by manuel.n...@gmail.com on 28 Mar 2014 at 1:16

[GoogleCodeExporter]

LeafletFinder is now AtomGroup/selection-string compliant.

Following the introduction of named groups (Issue 174) we have to decide how 
that reflects on other functions that take selection strings. This because 
named groups requires that a **kwargs dictionary be passed to the selection 
functions.
Should we:

1- Modify all functions that take selection texts to be **kwargs-aware for 
selection purposes? (which might be messy and bug-prone if they already manage 
some **kwargs);

or

2- Restrict the named group functionality to the selectAtoms family of 
functions? The user can then pass the returned AtomGroup to whatever function 
needs it.

I vote for 2. Feedback appreciated.

Original comment by manuel.n...@gmail.com on 29 Mar 2014 at 2:45

• Changed state: Started

[GoogleCodeExporter]

I am also in favor of (2) and only have selectAtoms() have special keyword 
(Issue 171) powers. I like the idea of using AtomGroups to pass around atom 
information as opposed to selection strings as the former seems to have a 
cleaner and more oo feel to it. 

The downside is that AtomGroups are static and do not work for selections that 
should update every frame, e.g. for hydrogen bond analysis.

Original comment by orbeckst on 15 Apr 2014 at 8:35