[Python] Aliasing cudaq name when importing it

[boschmitt]

Required prerequisites

• Consult the security policy. If reporting a security vulnerability, do not report the bug using this form. Use the process described in the policy to report the issue.
• Make sure you've read the documentation. Your issue may be addressed there.
• Search the issue tracker to verify that this hasn't already been reported. +1 or comment there if it has.
• If possible, make a PR with a failing test to give us a starting point to work on!

Describe the bug

In Python, it is quite common to alias the name of imported libs, e.g., import ... as .... It is common practice even for libraries which don't have big names: import numpy as np. If one tries to alias CUDA-Q import, things break.

Steps to reproduce the bug

import cudaq as quda

@quda.kernel
def simple():
    q = quda.qubit()

counts = quda.sample(simple)
print(counts)

Result:

cudaq.kernel.ast_bridge.CompilerError: bug0.py:5: error: Invalid function call - 'quda' is unknown.
	 (offending source -> quda.qubit)

Expected behavior

Correct execution. Users should be able to alias cudaq.

Is this a regression? If it is, put the last known working version (or commit) here.

Not a regression

Environment

• CUDA Quantum version: proto-0.8.0 (https://github.com/NVIDIA/cuda-quantum a9e2324)
• Python version: 3.12
• Operating system: ubuntu 24.04

Suggestions

No response

[mitchdz]

This should be possible with a small change. Let me take a stab at it.

[mitchdz]

If we are doing this, we might as well allow full aliasing such as:

from cudaq import kernel as k, qubit as qb

@k
def f():
    q = qb()

f()

[boschmitt]

This should be possible with a small change. Let me take a stab at it.

I'm don't think it will be a small change. The strings cudaq, numpy, np, qubit and friends are hardcoded in the bridge. In the end this is a symptom in of a deeper issue. Given your example, which I agree it should be supported:

from cudaq import kernel as k, qubit as qb

@k
def f():
    q = qb()

f()

cuda.qubit is not a object the bridge can reason about. Even before that, the bridge won't even try to resolve cudaq.qubit to an object, this is effectively a keyword in the current CUDA-Q. In this case, the bridge sees qb() and it does't know what to do about it. It is likely to be seen as a call to an unknown function.

The correct thing to do here would be something along these lines: resolve qb, seeing that qb = cuda.qubit, then the bridge gets the cudaq.qubit object and in it there should be a way to tell the bridge what to do on a call such as cudaq.qubit().

[mitchdz]

I got the import cudaq as quda change done with relatively small changes (only tested some simple examples). the qubit as qb is indeed proving to be challenging.