Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a python-defined layer over the bindings. #350

Closed
aborgna-q opened this issue May 21, 2024 · 2 comments
Closed

Add a python-defined layer over the bindings. #350

aborgna-q opened this issue May 21, 2024 · 2 comments
Assignees
Labels
py-bindings Python bindings

Comments

@aborgna-q
Copy link
Collaborator

Move the bindings to a tket2._tket2 submodule and re-define all structures from python, backed by their binded counterparts.

See Quantomatic/quizx for an example.

This gives us more flexibility on the python interface, where we can define methods that better reflect the python conventions.
Additionally, typing information is simpler and less error-prone; we only need the hand-written .pyi for the reduced binded methods and missing values will not affect the external API.

@aborgna-q aborgna-q added the py-bindings Python bindings label May 21, 2024
@aborgna-q aborgna-q self-assigned this May 21, 2024
github-merge-queue bot pushed a commit that referenced this issue May 22, 2024
First step towards #350.

Deinterlaces the rust-binded modules from the pure python ones. And puts
them in `_tket`
For now, we still re-export everything directly, I'll add the python
wrappers and missing typing info in a following PR.
github-merge-queue bot pushed a commit that referenced this issue May 24, 2024
Adds a python-side definition of `Tk2Op` and `Pauli`, so we can drop the
dependency on `pyo3` from the main rust package.

In addition of being necessary for #350, having only one package
depending on `pyo3` removes building headaches due to it linking to
python multiple times.

Blocked by #352
@ss2165
Copy link
Member

ss2165 commented Jul 9, 2024

Summary of in-person discussion:
Following on from #465, we intend to use hugr-py Node, Port, Wire types in the surface python layer. For ops and types, things like HugrType or TK2Ops should implement the hugr-py Op and Type protocols for compatibility. They should also compare as equal to their hugr-py counterparts.

@aborgna-q
Copy link
Collaborator Author

Closing this, as it will be included in any new tket2 bindings support / replaced by hugr-py uses.

@aborgna-q aborgna-q closed this as not planned Won't fix, can't repro, duplicate, stale Aug 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
py-bindings Python bindings
Projects
None yet
Development

No branches or pull requests

2 participants