-
Notifications
You must be signed in to change notification settings - Fork 71
Cleaning the code base #290
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
Changes from all commits
8749f71
4ec6a0d
ff243cc
df8195c
c822de0
511b526
3921dda
481d7d9
314c67a
50eac17
be723e4
b44e2a5
68e7edc
ad0e4df
6061c0f
49b36c0
1f64693
08a1826
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,9 +2,9 @@ | |
|
|
||
| import warnings | ||
|
|
||
| from .circuit import * | ||
| from .circuitsimulator import * | ||
| from ..operations import Gate, Measurement | ||
| from .circuitsimulator import CircuitResult, CircuitSimulator | ||
| from .circuit import QubitCircuit | ||
| from qutip_qip.operations import Gate, Measurement | ||
|
|
||
|
|
||
| def _add_deprecation(fun, msg): | ||
|
|
@@ -29,3 +29,10 @@ def newfun(*args, **kwargs): | |
| "The class Measurement has been moved to qutip_qip.operations." | ||
| "Please use update the import statement.\n", | ||
| ) | ||
|
|
||
|
|
||
| __all__ = [ | ||
| "CircuitSimulator", | ||
| "CircuitResult", | ||
| "QubitCircuit", | ||
| ] | ||
|
Comment on lines
+32
to
+38
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same as above. |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,10 +1,7 @@ | ||
| import numpy as np | ||
|
|
||
| from ..operations import Gate | ||
| from ..compiler import GateCompiler, Instruction | ||
|
|
||
|
|
||
| __all__ = ["SCQubitsCompiler"] | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is I think typically we do in qutip family package is to keep this in all
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This applies to many other files. |
||
| from qutip_qip.operations import Gate | ||
| from qutip_qip.compiler import GateCompiler, Instruction | ||
|
|
||
|
|
||
| class SCQubitsCompiler(GateCompiler): | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,7 @@ | ||
| """Unitary decomposition. (experimental)""" | ||
|
|
||
| from .decompose_single_qubit_gate import * | ||
| from .decompose_single_qubit_gate import decompose_one_qubit_gate | ||
|
|
||
| __all__ = [ | ||
| "decompose_one_qubit_gate", | ||
| ] |
Uh oh!
There was an error while loading. Please reload this page.
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 think for the
__init__.pyfiles, it is fine to use the star importation. We already defined__all__.pyin all the.pyfiles. This simplifies the development. Otherwise one have to always rember to update__init__.pywhen a new function is added.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.
And is there a reason that relative import is kept here but removed elsewhere? I don't have strong preference but it should be consistent.
Uh oh!
There was an error while loading. Please reload this page.
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.
In Python by defining
__all__in__init__.py, one is explicitly stating: "These are the tools intended for public use. Anything else you find in the submodules is internal logic and might change without warning." There were many cases of internal functions (starting with _) being exported through__all__in .py file which generally is not a good practice__all__in .py file is better, if we want to define the import at a file level instead of module level.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.
Generally relative imports are only kept at module level ( in
__init__.py). Relative imports from parent are strongly discouraged for large packages because refactor breaks a lot of things. One keeps the relative imports in__init__only because some people map a package directory to a different name in pyproject.tomlUh oh!
There was an error while loading. Please reload this page.
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.
For reference you can check: https://github.com/Qiskit/qiskit/blob/main/qiskit/quantum_info/__init__.py
Not defining
__all__in__init__.pyinherently means everything imported In__init__.pywill be exported when doesfrom package import *