You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Working on implicit or selections in issue #345 the following came up:
Our current selection parsing scheme is very robust. Each keyword token that is parsed consumes a defined number of subsequent token arguments. We never have to guess what's an argument and what's not.
This has the advantage that we never really have to reserve the use of keywords. The following would conceptually work:
# This selects atoms named 'and' from residues named 'and'.FUsel=u.selectAtoms("resname and and name and")
Now, this doesn't currently work only because at some point in the parsing of string selectors (resname, name, type, etc.) there's a check whether the argument is one of '(', ')', 'and', 'or', 'not', 'segid', 'resid', 'resname', 'name', or 'type'.
Note that blocking these keywords isn't really necessary for syntax. It just helps the user identify mistyped selections, since it's very unlikely an atom will be named ')' or 'and'. Still, this is a non-documented blacklist of reserved keywords, and a bit arbitrary, if you ask me, since selectAtoms("resname around") is valid but selectAtoms("resname name") isn't.
But why I'm asking for help/opinions here is that having implicit 'or' selections, as per issue #345, has the potential of letting pass selections that should fail. For instance selectAtoms("resname A nad around 10 protein") misses the mistyped 'and', and the result is a valid but nonsensical selection with residues that are named either 'A', 'nad', 'around', '10', or 'protein'.
So, should we expand the blacklist to encompass all keywords? The above would then fail when 'around' is reached, because there'd be no concatenation between that and the 'resnames' expression.
The only downside is that a system with names/resnames/types that happen to match one of our keywords won't be able to be properly name-searched. The VMD-style workaround for these fringe cases involves enclosing problematic names in quotes, which makes them arguments and not keywords:
FUsel=u.selectAtoms("resname 'and' and name 'and'")
So, please chip in.
The text was updated successfully, but these errors were encountered:
Allows selections such as:
u.select_atoms('name C N') == u.select_atoms('name C or name N')
u.select_atoms('name N and resname GLY LEU') == 'name N and (resname GLY
or resname LEU)'
Defines how to detect keywords in selection strings (`is_keyword`)
Issue #347
Implicit or in selections (Issue #345)
Allows selections such as:
``` python
u.select_atoms('name C* N* O*')
# == u.select_atoms('name C or name N')
u.select_atoms('name N and resname GLY LEU')
# == 'name N and (resname GLY or resname LEU)'
u.select_atoms('resid 1:10 14 15')
u.select_atoms('resid 1:100 200-300 and not resname MET GLY')
```
Defines how to detect keywords in selection strings with `is_keyword` (Issue #347).
Working on implicit or selections in issue #345 the following came up:
Our current selection parsing scheme is very robust. Each keyword token that is parsed consumes a defined number of subsequent token arguments. We never have to guess what's an argument and what's not.
This has the advantage that we never really have to reserve the use of keywords. The following would conceptually work:
Now, this doesn't currently work only because at some point in the parsing of string selectors (
resname
,name
,type
, etc.) there's a check whether the argument is one of'('
,')'
,'and'
,'or'
,'not'
,'segid'
,'resid'
,'resname'
,'name'
, or'type'
.Note that blocking these keywords isn't really necessary for syntax. It just helps the user identify mistyped selections, since it's very unlikely an atom will be named
')'
or'and'
. Still, this is a non-documented blacklist of reserved keywords, and a bit arbitrary, if you ask me, sinceselectAtoms("resname around")
is valid butselectAtoms("resname name")
isn't.But why I'm asking for help/opinions here is that having implicit
'or'
selections, as per issue #345, has the potential of letting pass selections that should fail. For instanceselectAtoms("resname A nad around 10 protein")
misses the mistyped'and'
, and the result is a valid but nonsensical selection with residues that are named either'A'
,'nad'
,'around'
,'10'
, or'protein'
.So, should we expand the blacklist to encompass all keywords? The above would then fail when
'around'
is reached, because there'd be no concatenation between that and the'resnames'
expression.The only downside is that a system with names/resnames/types that happen to match one of our keywords won't be able to be properly name-searched. The VMD-style workaround for these fringe cases involves enclosing problematic names in quotes, which makes them arguments and not keywords:
So, please chip in.
The text was updated successfully, but these errors were encountered: