Consider having autocomplete of backend names

[diego-plan9]

What is the expected behavior?

As per suggestion by @ajavadia , it might be nice for usability purposes to allow the names of the backends to be auto-completed in IDEs and interpreters.

For example, we could end up with provider.backends.poughkeepsie, etc. There are a number of subtleties involved (forcing the backend names to be valid Python member identifiers, conventions, etc) that need to be looked into and balance - hence labelling as discussion!

[jyu00]

I think this would be quite helpful as some of our backends have long names that are easily misspelled.

One way of doing this is to have a custom class (ProviderBackends maybe?) and just do setattr during backend discovery. The value of the attribute would point to the IBMQBackend object.

I don't think we need to worry too much about the backend names being valid Python identifiers, since it's highly unlikely we will have backend names with symbols other than an underscore. We can always validate them prior to the setattr and replace any unsupported characters with say an underscore (although collision will also need to be handled).

[jyu00]

This is what I have right now:

class ProviderBackends(SimpleNamespace):
    """Backend namespace for the provider"""

    def __init__(self, provider):
        """Creates a new ProviderBackends instance.

        Args:
            provider (AccountProvider): IBM Q Experience account provider
        """
        self._provider = provider
        self._initialized = False
        super().__init__()

    def _discover_backends(self):
        """Discovers the remote backends if not already known."""
        if not self._initialized:
            for backend in self._provider.backends():
                setattr(self, backend.name(), backend)
            self._initialized = True

    def __dir__(self):
        self._discover_backends()
        return super().__dir__()

    def __getattr__(self, item):
        self._discover_backends()
        return super().__getattribute__(item)

I'd appreciate some feedback on:

1. I ended up overwriting both __dir__ and __getattr__ to ensure backend information is not loaded until ProviderBackends attributes are referenced, either via autocomplete or explicitly.

2. ProviderBackends is a bit of a convoluted name. Some other ideas include BackendNamespace and BackendValues.

3. As mentioned in the previous comment, it's unlikely we'll have backend names with symbols other than underscores. If that's a concern we can validate the name and either raise an error or do some kind of mapping.

[ajavadia]

it's unlikely we'll have backend names with symbols other than underscores.

there are a number of other issues, such as should not contain space or should not start with a number. But all current backends currently adhere to this and there is no reason to expect that in the future they will not.

[jyu00]

Per @diego-plan9's request, here's the initial proposal for this new feature.

Requirements
Allows the names of the backends to be autocompleted in interactive sessions, such as Python shells or Jupyter Notebooks. A user can do autocomplete by, for example, pressing tab after provider.provider_backends. .

High level overview
A new attribute provider_backends will be added to AccountProvider, and it will be an instance of the new ProviderBackends class. The ProviderBackends class will inherit SimpleNamespace. The attributes of provider_backends will not be created until when provider_backends is first referenced, since backend discovery could take time.

Considerations

No.	Potential Issue	Potential Mitigation
1	Newer versions of Jupyter Notebook does greedy autocompletion by default. It would attempt to resolve provider.provider_backends attributes when the user does provider.<tab>.	This really is only an issue if the backend discovery takes a long time (see below).
2	Backend discovery may take a long time. In a Python shell, a user can interrupt the processing. In a Jupyter Notebook, however, it would appear as if autocomplete was not working.	We could put in a timeout value in the backend discover request when called by ProviderBackend. If the request times out, the autocomplete feature just won’t be available.
3	Backend discovery may fail. This would behave as if autocomplete was not working.	While it appears that the error raised would not be shown to the user, we should probably still catch and hide it. In this case the autocomplete feature won’t be available.
4	Backend names may not be valid Python identifiers.	Not really a high risk since all current backend names are valid identifiers, and that’s unlikely to change in the future. A potential solution to this problem, if it becomes a concern, is use a substitute backend name that is a variation of the actual one. For example, we can replace all “bad” characters with underscores, prepend it with a valid character, etc.
5	Backend discovery may yield partial results if some of the backends are not properly configured.	The faulty backend names will not show up under autocomplete. This is similar to the behavior of backend() except no warning messages will be given.
6	A user’s backends could change due to account status changes.	The user would have to disable and then re-enable the account, which is no different than what they would do when calling backends().