Deprecate PauliTable

[ikkoham]

Summary

• Deprecate PauliTable
• Deprecate StabilizerTable.pauli
• Make StabilizerTable a standalone (i.e. independent from PauliTable)

Details and comments

TODO

• Add Releasenote

[coveralls]

Pull Request Test Coverage Report for Build 1519291394

• 151 of 167 (90.42%) changed or added relevant lines in 3 files are covered.
• 3 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+0.01%) to 82.868%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/quantum_info/operators/symplectic/stabilizer_table.py	144	160	90.0%

Files with Coverage Reduction	New Missed Lines	%
qiskit/quantum_info/operators/symplectic/pauli_table.py	1	89.35%
qiskit/quantum_info/operators/symplectic/stabilizer_table.py	2	88.4%

Totals
Change from base Build 1517139552:	0.01%
Covered Lines:	50271
Relevant Lines:	60664

---

💛 - Coveralls

[ikkoham]

Milestone: 0.19
Label: Changelog: Deprecation, mod: quantum info

[chriseclectic]

Deprecating PauliTable is good, however keeping StabilizerTable is avoiding the problem that the API for StabilizerTable (which is the same as PauliTable) is outdated and needs to go too since it differs quite drastically in some cases from PauliList.

There is no real need for a separate StabilierTable class when its functionality is a strict subset of functionality of PauliList. The only place StabilizerTable is used is in the Clifford class where the differences are StabilizerTable uses a Z_2 phase instead of Z_4, and stores the table as a single array instead of X and Z arrays separately. This can be addressed by directly adding phase and array setter and getter methods to the Clifford class that convert the PauliList to these formats as they were in the old StabilizerTable (stack X and Z, convert phase to/from Z_2). Then all the internal code in Clifford should just has to replace obj.table.array and obj.table.phase with obj.array and obj.phase.

The stabilizer and stabilizer methods can be updated to return the internal PauliLists, and the table method itself could either return the full PauliList or be deprecated.

[jakelishman]

@chriseclectic: I'd recommend against having non-trivial @property getter methods; if x.phase constructs a new array on every access, it's very very easy to introduce big performance issues without noticing. If you're going to have data transformations on the class, it's probably best to put them in a "proper" function (so don't use @property), so it's clear at the call site that it's an expensive call - calling x.phase() multiple times looks wrong, which makes it safer from a performance perspective.

[ikkoham]

I'll modify this PR after #7269. (So, don't merge this)

[ikkoham]

I'll deprecate PauliTable and StabilzierTable at the same time in 0.23.