Add kwargs to arguments for Backend.get_compiled_circuit

[sjdilkes]

No description provided.

[cqc-alec]

Should probably add to changelog, as this is an API change.

[cqc-alec]

Suggested change

	self, optimisation_level: int = 2, **kwarfs
	self, optimisation_level: int = 2, **kwargs

[sjdilkes]

Now that's an embarrassing one, fixed!

[cqc-alec]

Suggested change

	self.default_compilation_pass(optimisation_level, kwargs).apply(return_circuit)
	self.default_compilation_pass(optimisation_level, **kwargs).apply(return_circuit)

[sjdilkes]

done

[cqc-alec]

Suggested change

	self.get_compiled_circuit(c, optimisation_level, kwargs) for c in circuits
	self.get_compiled_circuit(c, optimisation_level, **kwargs) for c in circuits

[sjdilkes]

done

[cqc-alec]

Ah! Is this going to break all the backends?

[sjdilkes]

Ah! Is this going to break all the backends?

Yeah, they're all going need to have **kwargs added to their corresponding default_compilation_pass methods. I think it's worth it to allow users to pass backend specific optimisation choices through the usual interface, and at least any existing user code will work fine.

[cqc-alec]

Ah! Is this going to break all the backends?

Yeah, they're all going need to have **kwargs added to their corresponding default_compilation_pass methods. I think it's worth it to allow users to pass backend specific optimisation choices through the usual interface, and at least any existing user code will work fine.

But it does mean that if someone updates pytket their code will stop working, which breaks the 1.x API promise.

We could make new Backend methods get_default_compilation_pass_v2, get_compiled_circuit_v2 and get_compiled_circuits_v2 which take the kwargs and call the existing methods by default, and override them in pytket-quantinuum (making the old methods call the new ones)?

[sjdilkes]

Ah! Is this going to break all the backends?

Yeah, they're all going need to have **kwargs added to their corresponding default_compilation_pass methods. I think it's worth it to allow users to pass backend specific optimisation choices through the usual interface, and at least any existing user code will work fine.

But it does mean that if someone updates pytket their code will stop working, which breaks the 1.x API promise.

We could make new Backend methods get_default_compilation_pass_v2, get_compiled_circuit_v2 and get_compiled_circuits_v2 which take the kwargs and call the existing methods by default, and override them in pytket-quantinuum (making the old methods call the new ones)?

Good point, I didn't think about people updating pytket but not the corresponding extension package.

That's a good idea - I'll do that now.

[sjdilkes]

Ah! Is this going to break all the backends?

Yeah, they're all going need to have **kwargs added to their corresponding default_compilation_pass methods. I think it's worth it to allow users to pass backend specific optimisation choices through the usual interface, and at least any existing user code will work fine.

But it does mean that if someone updates pytket their code will stop working, which breaks the 1.x API promise.
We could make new Backend methods get_default_compilation_pass_v2, get_compiled_circuit_v2 and get_compiled_circuits_v2 which take the kwargs and call the existing methods by default, and override them in pytket-quantinuum (making the old methods call the new ones)?

Good point, I didn't think about people updating pytket but not the corresponding extension package.

That's a good idea - I'll do that now.

Do you think I should also include optimisation_level in the kwargs?

[cqc-alec]

Rethinking this whole thing...