Qiskit / qiskit / 26544937605

88%

main: 88%

Build Type

push

github

Committed by web-flow

Commit Message

Unify Python custom instruction kinds (#15652)

* Unify Python custom instruction kinds

In gh-15277[^1] we unified the internal storage of the three variants of
Python operation in a single `PyOperationTypes` enum, where each variant
wraps the same `PyInstruction` type.  We didn't change the handling
within the `OperationRef` view object, to avoid modifying how all the
downstream matching would happen.

As we move towards removing the Python structures from `qiskit-circuit`
entirely, we will replace the field with a custom operation.  We will
have to decide how much of a type-level split between different objects
we want to maintain, and the "custom instruction" code will all have
down some form of dynamic-typing path.

As a stepping stone towards that, this commit moves the
`PyOperationTypes` enum discriminant into `PyInstruction` itself, which
has the knock-on effect of requiring `OperationRef` to reflect the same
backing structure. This was mentioned as a possibility in the original
PR, but not attempted at the time due to worries of less ergonomic
matching.

In practice, the matching is actually easier overall in this form
because of the significant de-deduplication in most cases; in
many cases, the handling of Python-space objects is independent of their
types.  With the `kind` field now inside `PyInstruction`, all the
methods of `PyInstruction` like `matrix`, which were _already_ fallible
can now simply handle the `Gate`/`Instruction`/`Operation` split
themselves, so there's no risk of a forgotten match causing trouble.

The legacy three-fold `Gate`/`Instruction`/`Operation` split is already
a relic of Python space that Rust _mostly_ shouldn't need to care about,
particularly the `Operation` element of it.  It may well make sense in
future custom gates to have a way of checking for "unitary" vs
"non-unitary" without requesting the matrix, but this is compatible with
`PyInstruction` being the single implementation of a "custom" gate from
Rust's ... (continued)

Coverage Stats

407 of 504 new or added lines in 29 files covered. (80.75%)

26 existing lines in 11 files now uncovered.

108481 of 123727 relevant lines covered (87.68%)

961620.08 hits per line