feat: setting sub_backends by default if they are available

[ShreyanshBardia]

part of task

With these changes I think this function becomes redundant and should be removed.

@vedpatwardhan

[github-actions]

PR Compliance Checks

Thank you for your Pull Request! We have run several checks on this pull request in order to make sure it's suitable for merging into this project. The results are listed in the following section.

Issue Reference

In order to be considered for merging, the pull request description must refer to a specific issue number. This is described in our contributing guide and our PR template.
This check is looking for a phrase similar to: "Fixes #XYZ" or "Resolves #XYZ" where XYZ is the issue number that this PR is meant to address.

[vedpatwardhan]

I'd suggest checking through the failing tests to see if any of the backend handler tests are related to the change made (which it most probably won't be).
Secondly, that line wouldn't be redundant but I suppose all the changes added in this PR would be (sorry @Madjid-CH 😅), because if a sub-backend wasn't set then it means either it wasn't installed or the user opted out. In either case we shouldn't be throwing the warning as a result of these changes. Could you please also revert those changes? Thanks @ShreyanshBardia 😄

[Madjid-CH]

I'd suggest checking through the failing tests to see if any of the backend handler tests are related to the change made (which it most probably won't be). Secondly, that line wouldn't be redundant but I suppose all the changes added in this PR would be (sorry @Madjid-CH 😅), because if a sub-backend wasn't set then it means either it wasn't installed or the user opted out. In either case we shouldn't be throwing the warning as a result of these changes. Could you please also revert those changes? Thanks @ShreyanshBardia 😄

do we have to consider if multiple sub-backends are available or we can ignore that for the moment since we currently only have one sub-backend ?
for example maybe we have an efficient implementation in another sub-backend a warning should be raised, right ?
or when setting a sub-backend by default, what's the criteria for such setting do we set the first one in the list or we should consider another factors for choosing a sub-backend.
Thanks @vedpatwardhan

[ShreyanshBardia]

Yes realised it later, we still would need to update original_backend_dict. It looks like you have already reverted the changes, let me know if anything else is needed. Also thhe test errors seem to be unrelated. Thanks @vedpatwardhan

[vedpatwardhan]

do we have to consider if multiple sub-backends are available or we can ignore that for the moment since we currently only have one sub-backend ? for example maybe we have an efficient implementation in another sub-backend a warning should be raised, right ? or when setting a sub-backend by default, what's the criteria for such setting do we set the first one in the list or we should consider another factors for choosing a sub-backend. Thanks @vedpatwardhan

Hey @Madjid-CH, I think the possibility of there being an implementation of multiple sub-backends for the same function is a bit rare, so we're not considering that for now. Basically for all functions if there's a sub-backend implementation it would be used by default on setting that backend if the library was installed. Hope that makes sense 😄

[vedpatwardhan]

Yes realised it later, we still would need to update original_backend_dict. It looks like you have already reverted the changes, let me know if anything else is needed. Also thhe test errors seem to be unrelated. Thanks @vedpatwardhan

Yep I've already reverted those changes, I think the PR is good to merge. Thanks @ShreyanshBardia 😄