creates cupydense in the data layer to be available as a Qobj

[MrRobot2211]

This lines were missing in order to be able to call operations from a Qobj and test all the functionality directly oin Qobjs.

[coveralls]

Pull Request Test Coverage Report for Build 1182844552

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 3 of 5 (60.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.4%) to 87.619%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/qutip_cupy/init.py	3	5	60.0%

Totals
Change from base Build 1127753560:	-0.4%
Covered Lines:	276
Relevant Lines:	315

---

💛 - Coveralls

[hodgestar]

This changes in this PR are probably unnecessary as they are:

• register_aliases already allows one to specify the dtype when creating a Qobj, although I would recommend adding "CuPyDense" to the list of aliases in the call to register_aliases.
• it's unnecessary to add a creator for a data layer type, but as @AGaliciaMartinez pointed out, it probably would be useful to add one for the cupy array type.

I think a setup similar to the one in https://github.com/qutip/qutip-tensorflow/blob/main/src/qutip_tensorflow/core/data/convert.py would make more sense.

[MrRobot2211]

@hodgestar I checked the diff and this one is ready.

[hodgestar]

Left two small comments, but looking much better.

[hodgestar]

Is the noqa really needed now that we import cupy as cp at the top?

[MrRobot2211]

The thing is that as the import is inside a try it fails to detect it

[hodgestar]

Could you double check?

When I do:

$ cat  foo.py
try:
    import math
except ImportError:
    raise


def f():
    print(math.pi)
$ flake8 foo.py

It doesn't print an error and in the code in this PR it doesn't print an error for del cp either.

[MrRobot2211]

Looks like there were some breaking changes on dev.major

[hodgestar]

Looks like there were some breaking changes on dev.major

Yep. Importantly data layer objects no longer support arithmetic operations via *, +, -, etc. For now I would pin the dependency of dev.major to the last working commit and then fix this in a later PR.