Instruction attributes have several inconsistencies across the API:
Instruction.CNOT is constructed as Instruction.CNOT(target, control), whereas Circuit.cnot(control, target). The same is true for RZZ and CCX.
Instruction.CZ is constructed as Instruction.CZ((u, v)), whereas Circuit.cz(u, v).
It seems less error-prone to use the same argument order everywhere (and the usual convention seems to be to put the control qubits first).
As for tuple v. expanded arguments, the situation is less clear. I think I prefer CCX(target=0, controls=(1, 2)) and ccx.controls[1] over CCX(target=0, control0=1, control1=2) and ccx.control1. The names control0 and control1 (or target0 and target1) seem more ad hoc.
Instruction attributes have several inconsistencies across the API:
Instruction.CNOTis constructed asInstruction.CNOT(target, control), whereasCircuit.cnot(control, target). The same is true forRZZandCCX.Instruction.CZis constructed asInstruction.CZ((u, v)), whereasCircuit.cz(u, v).It seems less error-prone to use the same argument order everywhere (and the usual convention seems to be to put the control qubits first).
As for tuple v. expanded arguments, the situation is less clear. I think I prefer
CCX(target=0, controls=(1, 2))andccx.controls[1]overCCX(target=0, control0=1, control1=2)andccx.control1. The namescontrol0andcontrol1(ortarget0andtarget1) seem more ad hoc.