-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Move OpenQASM 2 exporter to qiskit.qasm2
#10533
Conversation
This gets us into a position where the interface is similar between the `qasm2`, `qasm3` and `qpy` modules (all of which do vaguely similar things at an abstract level), which are in turn similar to functionality in the Python standard libraries. This commit simply moves the code from `QuantumCircuit.qasm` over to the new location. Some idiosyncrasies and additional bits of features that we do not intend to support long term (e.g. formatted output) are not brought over, but `QuantumCircuit.qasm` continues to perform those jobs until it is deprecated and removed.
One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 5717766407
💛 - Coveralls |
@classmethod | ||
@property | ||
@deprecate_func( | ||
since="0.45.0", additional_msg="No alternative will be provided.", is_property=True |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add something like handled by .qasm2.dumps, so no alternative is needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dunno - the use of this object is/was already done by internally QuantumCircuit.qasm
, so if someone's using it outside that context, then they presumably also don't want to use the new qasm2.dumps
.
@classmethod | ||
@property | ||
@deprecate_func( | ||
since="0.45.0", additional_msg="No alternative will be provided.", is_property=True |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM in general... some comments here and there.
:func:`.qasm2.dump` and :func:`.qasm2.dumps` | ||
The preferred entry points to the OpenQASM 2 export capabilities. These match the | ||
interface for other serialisers in Qiskit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just deprecate the .qasm
method? Or that's done somewhere else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is just adding the alternative now, so QuantumCircuit.qasm
isn't eligible for deprecation yet.
file.write(out) | ||
print(out, file=file) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this preferred? I always use the write
way. Am I doing it wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The print
call here ensures that a terminating newline character is added. Since dumps
returns an unterminated string (since that makes more sense for in-memory / interactive usage), I switched the file.write
to print
here so that the files would come out properly formatted without needing to string append \n
manually or needing to make two Python-space write
calls.
and exporting back to OpenQASM 2. The parsing components live in this module, while currently the | ||
export capabilities are limited to being the :meth:`.QuantumCircuit.qasm` method. | ||
Qiskit has support for interoperation with OpenQASM 2.0 programs, both :ref:`parsing into Qiskit | ||
formats <qasm2-parse>` and :ref:`exporting back to OpenQASM 2 <qasm2-export>`. | ||
|
||
.. note:: | ||
|
||
OpenQASM 2 is a simple language, and not suitable for general serialisation of Qiskit objects. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OpenQASM 2 is a simple language, and not suitable for general serialisation of Qiskit objects. | |
OpenQASM 2 is a simple language, and not suitable for general serialisation of Qiskit circuits. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd done this deliberately because QPY also allows serialisation of ScheduleBlock
, and sometimes the circuit structure is serialisable, but one or two of the contained instructions / expressions aren't. I can change it if you think that distinction is too subtle, though.
|
||
import pathlib | ||
|
||
qiskit.qasm2.dump(qc, pathlib.Path.home() / "myfile.qasm") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didnt know that pathlib.Path.home() / "myfile.qasm"
was possible. Nice one!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, pathlib
is typically a much more convenient interface to working with filesystems than raw os.path
, and almost everything that deals with path-like objects will accept T | os.PathLike[T]
as the type (for T: str | bytes
), of which pathlib.Path
is one.
become confused. | ||
deprecations: | ||
- | | ||
The little-used :class:`.QuantumCircuit` class data attributes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The little-used :class:`.QuantumCircuit` class data attributes | |
The :class:`.QuantumCircuit` class data attributes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to stress that these are highly unlikely to be in use, but can change it if you think it's much better not to.
Co-authored-by: Luciano Bello <bel@zurich.ibm.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's merge it!
Summary
This gets us into a position where the interface is similar between the
qasm2
,qasm3
andqpy
modules (all of which do vaguely similar things at an abstract level), which are in turn similar to functionality in the Python standard libraries.This commit simply moves the code from
QuantumCircuit.qasm
over to the new location. Some idiosyncrasies and additional bits of features that we do not intend to support long term (e.g. formatted output) are not brought over, butQuantumCircuit.qasm
continues to perform those jobs until it is deprecated and removed.Details and comments
Depends on #10532 because I copied across the new test from that as well - I didn't want that test to accidentally get lost later. The tests will fail on that one til that PR merges.