Enhancement: Python Bindings for Improved Usability and Integration

[zlatko-minev]

To increase the adoption and broader usability of this package within the research community, we propose adding Python bindings or a Python wrapper. This will enable integration with existing Python-based workflows and packages used by various research groups.

Proposed Solution:

Circuit-Level Interface:

• Create a well-defined interface at the quantum circuit level.
• Utilize a common quantum circuit abstraction (e.g., OpenQASM, QIR) as a universal translation layer.
• This approach will allow for direct porting of quantum circuits from popular frameworks like Qiskit, Cirq, and others into the simulation tools provided by this package.

Why? Increased Accessibility: Python is the dominant language in scientific computing and quantum computing research.

[MarcDrudis]

I have been thinking about this issue for some time now. I have explored 3 options so far:

1. Create a wrapper for a given python library that calls PauliPropagation.jl directly from python using JuliaCall from https://juliapy.github.io/PythonCall.jl.
2. Make circuits importable from a circuit abstraction in a file. It could use OpenQASM or QIR as suggested, or something simpler like a json file with a list of gates. Note that PauliSum should ideally also be saved and imported into other languages, but since it is already a dictionary, this step seems straightforward.
3. Compile PauliPropagation.jl using a tool like https://github.com/JuliaLang/PackageCompiler.jl. Then the code can be called more convinently form different languages without requiring a julia installation.

And these are my thoughts and what I have tried so far:

1. I have created a wrapper for Qiskit that integrates a simple function pauliprop_estimator(qc:QuantumCircuit,parameters:list[float],obs:SparsePauliOp). The implementation was a little bit cumbersome since one has to keep track of the indices of the parameters in Qiskit with respect to PauliPropagation.jl but it is overall not too complex. The main advantage I see to this approach is that it is easy to install for the user--a simplepip install qiskit_paulipropagation and having previously installed PauliPropagation.jl. However things got complicated when I tried to use multithreading and JuliaCall does not seem to be concieved for high performance computing.
2. While it would be appealing to use OpenQASM or QIR, neither of them have a good native solution for arbitrary Pauli rotations. Of course one can always decompose Pauli rotations into elementary gates, but in Qiskit for instance, a PauliRotation('XZX') would be decomposed when transformed into OpenQASM. Of course one could generate custom OpenQASM files that add a comment at each Pauli rotation definition indicating that this should be a pauli rotation of a given Pauli instead of just a bunch of gates, but it would not work out of the box for already existing QASM files nor for those generated by Qiskit, Cirq or any other major library. For those reasons, I believe I would directly go into a custom file .pp--or whatever we want to call it-- that is more "native" for the PauliPropagation.jl circuits. Something like a json file with:

• Name of gate
• Parameters(if any)
• Arguments
• Qubit registers

3. While in principle compiling a julia library is something that is in principle possible, I don't know how easy/convinient it would be, and it would definitely hinder the user's ability to play around with the libraries capabilities and use it for specific applications--this would apply specially to power users. For less intensive users, having a binary that we can ship with a python package that runs a circuit and observable and yields an expectation value would probably be more than enough.

And the three approaches are not exclusive. I believe defining 2 should be a priority so that it can be used with approaches 1 and 2. I can also imagine a pipeline where python generates temporary files with the circuit structure and julia generates an other temporary file with the propagated observable or the result of some evaluations. Likewise, I can also imagine having a compiled binary that gets directly called from python and we only expose a few functions.

[zlatko-minev]

Thank you, Marc. This is very thoughtfully done.

I have not yet done jupyter bindings from python, in the past, with python to other languages, I have usually used something like option #1. Where the package would also have some interface functions to convert say a qiskit circuit to the right format.

How much multithreading are you using now? If i launch a process from python, such as a sweep, is the issue that PauliPropagation.jl cannot now in its julia env launch a multi-threaded instance, or the async collection of the results gathering is the issue?

[MarcDrudis]

Thank you for the quick response :)
Option 1 is working quite well BUT the user still has to install julia and PauliPropagation.jl, which might be a lot of friction for some users. In reference to multithreading, you are right. The way that JuliaCall works is that python creates 1 thread with a julia process and then executes the julia code on it. I have tried both multithreading in python executing different julia processes--which fails because each thread tries to access the same julia process-- and calling from python a julia function that uses julia's multithreading--which works but since it only has one thread it is kind of pointless. That said, for a lot of applications 1 thread should be enough.

An other obstacle that I encountered is creating a nice setup.py such that on pip install it would automatically create a julia environement with PauliPropagation on it--that way we only require the user to have installed julia previously.

An other thing I don't love is that some of the code is executed from a python string--which I believe is usually regarded as unsafe. Something like seval("Dict{Int, Int}")() in order to create a julia dictionary from python. This could be mitigated with 2 since we could just pass the circuit abstraction to julia and julia would be the one creating the circuit instead of creating the julia objects from python.

PS: I think you have accidentally mentioned a PR.

[zlatko-minev]

Thanks for the quick reply back. Yes, I agree. It would be really nice if we could get it to just be a Pan style. Although I would think it’s also OK to require to install Pip install and then do a Julia install. At least there’s a shorter term solution. Sent from my iPhoneOn Feb 27, 2025, at 3:23 PM, Marc Sanz Drudis ***@***.***> wrote: Thank you for the quick response :) Option 1 is working quite well BUT the user still has to install julia and PauliPropagation.jl, which might be a lot of friction for some users. In reference to multithreading, you are right. The way that JuliaCall works is that python creates 1 thread with a julia process and then executes the julia code on it. I have tried both multithreading in python executing different julia processes--which fails because each thread tries to access the same julia process-- and calling from python a julia function that uses julia's multithreading--which works but since it only has one thread it is kind of pointless. That said, for a lot of applications 1 thread should be enough. An other obstacle that I encountered is creating a nice setup.py such that on pip install it would automatically create a julia environement with PauliPropagation on it--that way we only require the user to have installed julia previously. An other thing I don't love is that some of the code is executed from a python string--which I believe is usually regarded as unsafe. Something like seval("Dict{Int, Int}")() in order to create a julia dictionary from python. This could be mitigated with 2 since we could just pass the circuit abstraction to julia and julia would be the one creating the circuit instead of creating the julia objects from python. PS: I think you have accidentally mentioned a PR.—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***> MarcDrudis left a comment (MSRudolph/PauliPropagation.jl#51) Thank you for the quick response :) Option 1 is working quite well BUT the user still has to install julia and PauliPropagation.jl, which might be a lot of friction for some users. In reference to multithreading, you are right. The way that JuliaCall works is that python creates 1 thread with a julia process and then executes the julia code on it. I have tried both multithreading in python executing different julia processes--which fails because each thread tries to access the same julia process-- and calling from python a julia function that uses julia's multithreading--which works but since it only has one thread it is kind of pointless. That said, for a lot of applications 1 thread should be enough. An other obstacle that I encountered is creating a nice setup.py such that on pip install it would automatically create a julia environement with PauliPropagation on it--that way we only require the user to have installed julia previously. An other thing I don't love is that some of the code is executed from a python string--which I believe is usually regarded as unsafe. Something like seval("Dict{Int, Int}")() in order to create a julia dictionary from python. This could be mitigated with 2 since we could just pass the circuit abstraction to julia and julia would be the one creating the circuit instead of creating the julia objects from python. PS: I think you have accidentally mentioned a PR. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[MSRudolph]

Hi, just letting y'all know that we have a new example notebook on dev that shows how to use PP.jl from Python via JuliaCall: https://github.com/MSRudolph/PauliPropagation.jl/blob/dev/examples/PP-from-Python.ipynb

[zlatko-minev]

Cool!! 😎 Sent from my iPhoneOn Jun 13, 2025, at 5:30 AM, Manuel S. Rudolph ***@***.***> wrote:MSRudolph left a comment (MSRudolph/PauliPropagation.jl#51) Hi, just letting y'all know that we have a new example notebook on dev that shows how to use PP.jl from Python via JuliaCall: https://github.com/MSRudolph/PauliPropagation.jl/blob/dev/examples/PP-from-Python.ipynb —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[jlapeyre]

A clarification: using PackageCompiler.jl as suggested in #51 (comment) will not buy you anything. It only potentially reduces loading and precompilation time. It won't have any effect on interface options.

It looks like you are onto other solutions in any case. But I wanted to draw a line through that option for completeness.