Type hint for analysis module

[umak1106]

Fixes #

Changes made in this Pull Request:

PR Checklist

• [ ] Tests?
• [ ] Docs?
• [ ] CHANGELOG updated?
• [ ] Issue raised/referenced?

[pep8speaks]

Hello @umak1106! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

• In the file package/MDAnalysis/analysis/dihedrals.py:

Line 449:5: E303 too many blank lines (2)

• In the file package/MDAnalysis/analysis/gnm.py:

Line 155:80: E501 line too long (81 > 79 characters) Line 260:33: E252 missing whitespace around parameter equals

• In the file package/MDAnalysis/analysis/leaflet.py:

Line 147:80: E501 line too long (105 > 79 characters) Line 218:80: E501 line too long (86 > 79 characters) Line 268:80: E501 line too long (93 > 79 characters) Line 270:80: E501 line too long (89 > 79 characters)

• In the file package/MDAnalysis/analysis/lineardensity.py:

Line 197:80: E501 line too long (108 > 79 characters)

Comment last updated at 2022-08-20 16:46:41 UTC

[codecov[bot]]

Codecov Report

Merging #3752 (c5767df) into develop (6302b4c) will increase coverage by 0.00%. The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           develop    #3752   +/-   ##
========================================
  Coverage    94.30%   94.31%           
========================================
  Files          192      192           
  Lines        24777    24816   +39     
  Branches      3341     3341           
========================================
+ Hits         23367    23406   +39     
  Misses        1362     1362           
  Partials        48       48           

Impacted Files	Coverage Δ
package/MDAnalysis/analysis/align.py	98.34% <100.00%> (+0.02%)	:arrow_up:
package/MDAnalysis/analysis/bat.py	97.63% <100.00%> (+0.04%)	:arrow_up:
package/MDAnalysis/analysis/contacts.py	100.00% <100.00%> (ø)
package/MDAnalysis/analysis/density.py	100.00% <100.00%> (ø)
package/MDAnalysis/analysis/dielectric.py	100.00% <100.00%> (ø)
package/MDAnalysis/analysis/diffusionmap.py	100.00% <100.00%> (ø)
package/MDAnalysis/analysis/dihedrals.py	100.00% <100.00%> (ø)
package/MDAnalysis/analysis/distances.py	100.00% <100.00%> (ø)
package/MDAnalysis/analysis/gnm.py	99.22% <100.00%> (+0.01%)	:arrow_up:
package/MDAnalysis/analysis/leaflet.py	96.47% <100.00%> (+0.17%)	:arrow_up:
... and 4 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[jbarnoud]

Do not forget to stop ignoring the module in thee mypy config file.

[jbarnoud]

package/MDAnalysis/analysis/polymer.py:78: error: "AtomGroup" has no attribute "__iter__" (not iterable)
package/MDAnalysis/analysis/polymer.py:87: error: "AtomGroup" has no attribute "__iter__" (not iterable) 

There are a bunch of errors like this one. We can iterate on groups because they have getitem and len. This make them sequences that mypy does not identify as being iterable. I do not know how to solve this issue at the moment. Any idea would be welcome.

[hmacdope]

Random guesses but does using

'''python def iter(): pass '''

or the forward declaration as a string

'''python ag: 'AtomGroup' '''

[jbarnoud]

@ALescoulie these 2 mypy errors are about one of your recent changes. Maybe you are interested in having a look?

package/MDAnalysis/analysis/nucleicacids.py:134: error: Incompatible types in assignment (expression has type "List[<nothing>]", variable has type "Type[List[Any]]")
package/MDAnalysis/analysis/nucleicacids.py:141: error: Too few arguments for "append" of "list"

[jbarnoud]

Random guesses but does using

'''python def iter(): pass '''

or the forward declaration as a string

'''python ag: 'AtomGroup' '''

I expect redefining __iter__ to just pass will simply break the ability to iterate on groups.

I do not see how a forward declaration would help here. Could you elaborate?

[jbarnoud]

Here is a common pattern that is annoying mypy : an attribute is set to None in init, it is given a value in prepare, single_frame and conclude assume that the attribute has a non-None value.

The assumption is correct viewed from our use case. Indeed, single_frame and conclude are only called by run, therefore always after prepare.

What mypy sees however is that the attributes may be None and we recklessly call methods on what could be None.

I see 2 possibilities here.

Either we go for our assumption and we ignore the errors. I don't like it because it is easy to miss actual errors when we are too ready to ignore them.

Or we go for the no-assumption approach from mypy and we put guards in the code to avoid tripping onto a None. But this makes the code more complex and maybe less performant.

Maybe somebody has ideas here?

[ALescoulie]

@jbarnoud I'll look when I get home. It shouldn't be too hard to fix.