-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Removing consider-using-enumerate from lint exclusions and updates #12286
base: main
Are you sure you want to change the base?
Removing consider-using-enumerate from lint exclusions and updates #12286
Conversation
Pull Request Test Coverage Report for Build 9295747340Details
💛 - Coveralls |
Thank you for opening a new pull request. Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone. One or more of the the following people are requested to review this:
|
# Conflicts: # pyproject.toml
@mtreinish as a heads up, the latest commit probably needs your eyes. specifically in the |
qiskit/transpiler/passmanager.py
Outdated
original_qubits_reverse = {v: k for k, v in original_qubit_indices.items()} | ||
original_qubits = [] | ||
for i in range(len(original_qubits_reverse)): | ||
original_qubits.append(original_qubits_reverse[i]) | ||
for v, k in original_qubits_reverse.items(): | ||
original_qubits.append(k) |
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 looks like a behavioural change to me. Dictionary iteration order is insertion order, but the previous form was specifically looking up in numerical order of the v
items.
The v
s are ints here (from 0
to n-1
) and the k
are Qubit
instances.
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.
ah, i see it now. ok, i'll have to update this
Thank you for opening a new pull request. Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone. One or more of the the following people are requested to review this:
|
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.
Overall this LGTM, just one question/comment inline about the changes in passmanager.py
original_qubits = [None] * len(original_qubit_indices) | ||
for k, v in original_qubit_indices.items(): | ||
original_qubits[v] = k |
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'm mildly worried about this logic in the failure mode here. If somehow original_qubit_indices
was incorrectly constructed and missing an index this wouldn't catch that. We'd never know that there was an entry in the list which was None
and I just checked that virtual_permutation_layout.inverse()
doesn't error if it gets None
on an input element (which itself seems like a bug).. I liked the previous logic because it would error if you original_qubit_indices
was incorrectly constructed.
While it's not critical and I think this would not be an issue in practice, I'm just wondering if we need to make this change here? Like if pylint flagging this I'm wondering if a local exclude makes more sense in this case.
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.
Would it be sufficient to add a check after regenerating original_qubits
?
if None in original_qubits:
raise ValueError("original_qubit_indices is missing an index")
Summary
#9614 - removing consider-using-enumerate
Details and comments
Updates for removing this rule if wanted. Open to suggestions on variable names