search

qua-platform / quam

The Quantum Abstract Machine (QuAM) is a comprehensive framework designed to abstract and manage quantum programming environments, providing robust tools for configuring and running quantum operations effectively. It is built over the QUA programming language, offering an organized structure for handling complex quantum components and operations.
http://qua-platform.github.io/quam/
BSD 3-Clause "New" or "Revised" License
4 stars 2 forks source link

quam_dataclass with optional attributes #46

Closed anton-buyskikh closed 1 month ago

anton-buyskikh commented 1 month ago

It's more of a question rather than a bug report. I'd like to understanding what is the intended way or working with optional attributes in quam_dataclass.

For instance, if a new attribute param_x: int | None = None is added to the Transmon class in your example https://github.com/qua-platform/quam/blob/c24f3642dfb4609923f50fc13dbe19818c9c527a/quam/examples/superconducting_qubits/components.py#L12 then generate_superconducting_quam.py works just fine. The default None is serialised/deserialised successfully. It also works successfully with either include_defaults flag in QuAM.save.

However, if I provide a integer value on initialisation and rerun generate_superconducting_quam.py the following error is raised: TypeError: Instantiation for type int | None in QuAM.qubits["q0"].param_x not implemented.

It seems like this error is raised only for primitive types, and if I correct the type in line https://github.com/qua-platform/quam/blob/c24f3642dfb4609923f50fc13dbe19818c9c527a/quam/examples/superconducting_qubits/components.py#L17 to optional, such as xy: IQChannel | None = None then the deserialisation works fine.

nulinspiratie commented 1 month ago

Hi @anton-buyskikh I would say this is a perfect bug report! It seems the issue arises when using the pipe operator rather than e.g. Optional[int], it turns out that in this case the type origin is types.UnionType rather than typing.Union. I have fixed this in PR #47

Thanks for submitting this! And feel free to reach out if you need help with anything

anton-buyskikh commented 1 month ago

@nulinspiratie thanks for a quick response, I'll give it try soon! Just wanted to add that issue might have been still relevant for other standard datatypes, like float, complex, bool, str, list, ... I haven't checked them yet.