Add type annotations to the PauliTerm class

[rht]

Description

Only PauliTerm is annotated to keep this PR small.

Checklist

• The above description motivates these changes.
• There is a unit test that covers these changes.
• All new and existing tests pass locally and on Semaphore.
• Parameters have type hints with PEP 484 syntax.
• Functions and classes have useful sphinx-style docstrings.
• (New Feature) The docs have been updated accordingly.
• (Bugfix) The associated issue is referenced above using
  auto-close keywords.
• The changelog is updated,
  including author and PR number (@username, gh-xxx).

[rht]

Based on #147.

[notmgsk]

Please complete the checklist (namely, fill out the changelog).

Paging the resident mypy expert @appleby.

[appleby]

Looks good @rht, thanks for the PR. I noticed in the linked issue there were problems type checking numbers.Number. Is that still an issue?

Also, does mypy report any errors/warnings when running with --strict ? E.g.

mypy --ignore-missing-imports --follow-imports=silent --strict pyquil/paulis.py

[rht]

I have added a description of the PR into the changelog.

[rht]

Also, does mypy report any errors/warnings when running with --strict ? E.g.

There are lots of errors/warnings still because not everything inside paulis.py has been annotated yet. Hopefully the number of errors/warnings become tractable as more of the functions become annotated.

[appleby]

Minor stuff. Otherwise looks good.

Github won't let me comment on lines that don't have diff, so mentioning here: there appear to be a handful of PauliTerm methods that are missing return type hints. (I suspect these methods were added after your original PR.) Would you mind adding type hints for them? E.g.

• operations_as_set
• __hash__
• program
• __iter__

[rht]

@appleby I have applied your patches to the PR. I will add annotations to the remaining 4 methods, and I will report when I'm done.

[rht]

@appleby I added operations_as_set, __hash__, program, __iter__ annotations in the second commit.

[appleby]

two more small changes; otherwise looks good.

[rht]

The second commit has been squashed.

[rht]

There is an inconsistency with PauliTerm's __init__() where the coefficient argument should have been a Number instead of Union[int, float, complex]. But I want to keep this PR compact. I will do a subsequent PR that addresses these issues later.

[appleby]

There is an inconsistency with PauliTerm's __init__() where the coefficient argument should have been a Number instead of Union[int, float, complex]. But I want to keep this PR compact. I will do a subsequent PR that addresses these issues later.

Given this mypy issue that you pointed out in #147, which seems to imply that numbers.Number is somewhat useless for type checking, maybe we should go the other route and switch all the Numbers to Union[int, float, complex] (as unsatisfying as that would be).

[appleby]

There are still some issues to work out, mostly around the arithmetic operations, but I think that is an issue of mypy needing more help to correctly infer types. The types added in this PR look reasonable, so I feel OK taking a gradual approach and adding more type hints to the module in a follow on PR.

[rht]

Given this mypy issue that you pointed out in #147, which seems to imply that numbers.Number is somewhat useless for type checking, maybe we should go the other route and switch all the Numbers to Union[int, float, complex] (as unsatisfying as that would be).

There is an extra complication due to the fact that the code uses isinstance(x, Number) which works, since a complex object is an instance of Number. Using different convention for type hints (i.e. Union[int, float, complex]) and type checking in code would cause conflict.

[rht]

I already have PauliSum annotation done. Just waiting for this PR to be merged, then I will make a new PR of PauliSum.

[karalekas]

I will give this a review as soon as I've gotten @appleby's typing PR over the line -- thanks for doing this! :)

[rht]

I just rebased to get rid of the merge conflict. @karalekas any update?

[karalekas]

@rht this looks great, and I'm looking forward to the follow-on PR. only thing that needs changing is moving your changelog entry to the new v2.14 "Improvements and Changes" section, which will require you to rebase off of master first

[rht]

@karalekas rebased and moved the line to be under v2.14.

[karalekas]

@rht thanks for contributing to pyQuil! :)