How to use pass_operation_over with cirq.Operation? [closed]

Question

Lately I saw a pull request in the Cirq GiHub repo where some dev said a test should be defined, with these constraints: You need to find a case where a cirq.Operation that is not a cirq.GateOperation is passed to

Cirq/cirq/ops/pauli_string.py

Line 943 in 4bb484a

 def _pass_operation_over(

I follow the project, sadly I have no time to contribute, though. I have been using Cirq for a long time, and this "puzzle" got me puzzled, as I have never used anything similar. Could someone please give me an example of something like this? I ussually use cirq.GateOperation in college, and not this stuff. Btw, idk how often those developers read silly questions like this, but maybe they'll find this helpful for their project, idk. This is the comment I'm talking about. Waiting for a response... Thanks.

Answer 1

This is a pretty technical internal detail of how cirq works.

Basically what's going on is that cirq's continuous integration system verifies test coverage. If you contribute to cirq and you touch a line of code, there's supposed to be at least one test that runs that line (or else an # coverage: ignore annotation on the line). The "only touched lines matter" nature of this check makes it possible for uncovered lines to exist (e.g. by changes that delete tests without touching the lines that become uncovered, or by grandfathered lines that existed before the coverage check), so the coverage of the project is not 100%. The coverage check is more of a "give me evidence that you actually tried this" check when adding code.

Anyways, in that particular PR the coverage check is complaining that a line is not being tested. This line is tricky to actually hit, because it's explicitly about a case not being handled. (The line is raise TypeError(f'Unsupported operation: {op!r}')). Often these lines aren't even reachable. They're just defensive programming ensuring that if this internal method is called incorrectly that it will stop instead of charging forward making things worse and more confusing. In normal situations the method is simply called correctly.

The correct fix in this situation is not to cover the line (generally you don't want to assert for all time that a particular case must not work) but to annotate the line as not covered. Actually, one of the built-in escape valves for the coverage check is that any line throwing a NotImplementedError doesn't need to be covered, so really only the type of exception being raised needs to change.