GitLab

* Use list-comprehension in Python code

A minor change, but slighly easier to understand the initialization of
`parent_exclude_list` in my opinion.

* Implement __ne__ in Python classes that has __eq__

In Python 3, `__ne__` is automatically implemented as `not __eq__`.

However, in Python 2 it seems to be implemented as `not is` (so based on object
identity).

Based on setup.py [0] which says that "OpenMM requires Python 2.7 or better", it
should be useful to have better support for Python 2 :)

This was already done in 4 of the 12 classes that implements `__eq__`

```
>>> class WildCard(object):
...     def __eq__(self, other): return True

>>> w = WildCard()

>>> w == 42
True

>>> w != 42
True

>>> w != w
False
```

[0]: https://github.com/openmm/openmm/blob/5cef29ce8d4e17b6d0f9fd8a3c6cc1669ca0ba2b/wrappers/python/setup.py#L237

* Use umambiguous floor division for index calculations in Python

This makes the code work as intended if run as Python 3

```
$ python2 -c 'print(3/2, 3//2)'
(1, 1)
$ python3 -c 'print(3/2, 3//2)'
1.5 1
```

* Use `with` for file handling in Python

* Use `is None` instead of `== None` in Python

This is recommended in PEP8:

> Comparisons to singletons like None should always be done with is or is not, never the equality operators.
> - https://www.python.org/dev/peps/pep-0008/#programming-recommendations

Swigged python docstrings now include documented return values and type
information or their arguments. They are generated in numpydoc format.
Furthermore, all of the Python app layer docstrings have been changed
to numpydoc format. The filterPythonFiles.py script which helps to
generate the Doxygen Python API docs has been updated to reflect these
changes.

Apparently CHARMM PSF files (particularly those printed by VMD's psfgen) can
have an insertion code tacked on to the end of the residue number, meaning that
casting to an integer will invariably fail.  We can't just ignore the insertion
code, though, since it will differentiate from the residues that came before and
after (which will likely have the same number -- same general idea as insertion
codes from PDB files). So instead we pull the insertion code off of the residue
number and extend the Residue object to accommodate that.

This is the port of the fix from ParmEd: ParmEd/ParmEd#98

I added a test for this case.

    - Adjust CharmmPsfFile parser to accept multiple blank lines before the
      NATOM record (I saw 1 PSF file like this... not sure how common it really
      is)
    - Removed the shebang line from element.py and removed execute permissions--
      it should never be executed directly (evidenced by the fact that the
      original shebang line was wrong and would never work, anyway).
    - Fix a test to determine if a Bond is part of an Angle in the PSF data
      structures.

(which means that consecutive residues may have the same residue number _and_
name, but are different residues).

pick up some bugs that were not caught in my initial test following the port
from ParmEd.

All 4 tests pass right now, although no periodic systems are being tested.
Currently CHARMM, XPLOR, and VMD tests are all being run (for the same ala-3
system).

Disable implicit solvent tests, since there is no robust radii assignment
routine yet (the radii are stored in the Amber topology file).  I will port my
assignment routine from ParmEd here shortly and then re-enable the GB tests.

Currently gives exactly the same energy as the same files passed through chamber
(which, in turn, was validated to machine precision against CHARMM itself).