[WIP] Split PyDAGCircuit from DAGCircuit #15301
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit splits out the Python only component of the DAGCircuit struct in Rust. The DAGCircuit struct has two fields that explicitly require Python, `metadata` and `duration`, and there are two more fields that are only ever used in Python, `unit` and `name` despite both being strings. To make the Python component distinct and separable this makes a separate Python interface struct PyDAGCircuit which wraps the inner pure rust DAGCircuit that contains the extra data for Python. This struct also defines all the Python methods so the inner rust DAGCircuit doesn't define any interface to Python anymore and it's all isolated to the This commit will prepare us towards implementing Qiskit#14240 to make pyo3 and needing python symbols a compile time option. While it is possible to conditionally compile all these aspects everywhere there are a few advantages an explict stuct provides. The first is making all the places we expect a Python interface very explicit. This makes it easy to reason about special handling only needed for python and isolate it to separate blocks. It also reduces the code complexity for when we do insert conditional compilation features, because we only need to add the cfg attributes to a few outer places instead of handling it internally in every spot something from Python is used. Looking to the future the long term goal this split enables is moving the Python aspects of the DAGCircuit and the transpiler to the pyext crate. Having all the Python interface components be separate structs and functions means when we finish the data model migration all these interface points can just be moved to the pyext crate since they'll be self contained. We can't do that yet as control flow is still dependent on the Python interface.
mtreinish
added
on hold
mtreinish
added
the
Rust
Shivam-Bhardwaj
added a commit
to Shivam-Bhardwaj/qiskit
that referenced
this pull request
Nov 16, 2025
Replace .unwrap() calls in pack_into and unpack_into methods with proper error handling to prevent panics when converting circuits with control flow operations to DAGs. This fixes the TODO mentioned in PR Qiskit#15301 about test failures/panics with control flow (circuit to dag issues). Changes: - Replace .unwrap() on qubits.find() with ok_or_else() returning DAGCircuitError - Replace .unwrap() on clbits.find() with ok_or_else() returning DAGCircuitError - Replace .unwrap() on vars.find() with ok_or_else() returning DAGCircuitError - Replace .unwrap() on qubits.get() with ok_or_else() returning DAGCircuitError - Replace .unwrap() on clbits.get() with ok_or_else() returning DAGCircuitError - Replace .unwrap() on vars.get() with ok_or_else() returning DAGCircuitError All control flow tests now pass successfully.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This commit splits out the Python only component of the DAGCircuit struct in Rust. The DAGCircuit struct has two fields that explicitly require Python,
metadataandduration, and there are two more fields that are only ever used in Python,unitandnamedespite both being strings. To make the Python component distinct and separable this makes a separate Python interface struct PyDAGCircuit which wraps the inner pure rust DAGCircuit that contains the extra data for Python. This struct also defines all the Python methods so the inner rust DAGCircuit doesn't define any interface to Python anymore and it's all isolated to theThis commit will prepare us towards implementing #14240 to make pyo3 and needing python symbols a compile time option. While it is possible to conditionally compile all these aspects everywhere there are a few advantages an explict stuct provides. The first is making all the places we expect a Python interface very explicit. This makes it easy to reason about special handling only needed for python and isolate it to separate blocks. It also reduces the code complexity for when we do insert conditional compilation features, because we only need to add the cfg attributes to a few outer places instead of handling it internally in every spot something from Python is used. Looking to the future the long term goal this split enables is moving the Python aspects of the DAGCircuit and the transpiler to the pyext crate. Having all the Python interface components be separate structs and functions means when we finish the data model migration all these interface points can just be moved to the pyext crate since they'll be self contained. We can't do that yet as control flow is still dependent on the Python interface.
Details and comments
TODO: