Replace get_backend with backend in the README

[yaelbh]

The method get_backend has been renamed to backend, but the README was not updated.

Grepping get_backend, it still appears in additional places in the code (fake provider and integration tests); these possibly should be updated too.

[merav-aharoni]

In qiskit-terra, ProviderV1 uses get_backend() rather than backend(). JobV1 uses backend(). So I guess that for QiskitRuntimeService we should actually use get_backend(), and remove the method `backend() (deprecate first). @kt474 , @jyu00 - please approve before I make the change.

[jyu00]

Yeah it looks like we have both backend() and get_backend() for a while now, and neither is marked as deprecated. Since QiskitRuntimeService inherits from ProviderV1, I agree it makes more sense to remove backend() (especially since we can't remove a parent method).

[kt474]

Do we really want to remove backend()? It's used all over our documentation/tutorials and I feel like it's the more popular option. Also it makes more sense to have a backends() method that returns multiple backends and a backend() method that returns a single backend. Removing this method would require most of our users to switch to get_backend().

Also - just noticed that get_backend() was added later here in https://github.com/Qiskit/qiskit-ibm-runtime/pull/419 to add "provider compatibility"

[jyu00]

Well since get_backend() is defined in the parent class, our choices are

1. Keep them both
2. Remove backend()
3. Have a ProviderV2 to rename get_backend() to backend()
4. Stop inheriting from Provider

I'm not a big fan of (1) because we'd have different methods that do the same thing. (3) is not worth the hassle, and (4) is a possibility but we'd be breaking away from Qiskit Provider, which is not a huge deal but it'd be nice if things under the Qiskit umbrella are more consistent.

@1ucian0 do you have any thoughts on this?

[1ucian0]

From the discussion in the providerV2 PR (Jan 2021, https://github.com/Qiskit/qiskit/pull/5629 ) @mtreinish raises the point that the Provider abstract class does not bringing much. Qiskit knows about backends independently from where they come. I think option 4 is simpler for qiskit-ibm-runtime and, probably, for all the providers out there.

[jyu00]

From the discussion in the providerV2 PR (Jan 2021, Qiskit/qiskit#5629 ) @mtreinish raises the point that the Provider abstract class does not bringing much. Qiskit knows about backends independently from where they come. I think option 4 is simpler for qiskit-ibm-runtime and, probably, for all the providers out there.

@1ucian0 I don't see any specific comment in that PR regarding the value of Provider. Does Qiskit plan to deprecate/remove Provider entirely? Even though option 4 is the easiest, do we really want qiskit-ibm-runtime to be the only one that uses backend() whereas the rest providers have get_backend()?

[1ucian0]

We did not explicitly thought about it yet, but maybe now is a good moment for that, towards 1.0.

Here a summary for reasons to drop it:

• ProviderV1 does not give you much: name, backends, and get_backend. That's it. And one of their names is debatable.
• A provider is a collection of backends. Backend is the actual thing that Qiskit cares about. Providers are not structures that Qiskit handles around (like it used to https://github.com/Qiskit/qiskit-ibm-runtime/pull/419), so there is no need to prescribe a specific API
• Different providers have, for example, different credential handling. So having a different way to fetch a backend looks like minor to me.

If you think the discussion is controversial enough, I could open a short RFC.

[jyu00]

ok so the conclusion is that QiskitRuntimeService will stop inheriting from Provider, with the expectation that Provider will be going away. QiskitRuntimeService will then free to use backend() instead of get_backend().