Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

tnemoz
Copy link
Contributor

@tnemoz tnemoz commented Sep 14, 2025

Summary

This PR modernizes the linting and type hinting of the repository, akin to qiskit-community/qiskit-optimization#676.

Details and comments

  • An initial ruff pass with the following configuration has been done:
line-length = 100
target-version = "py310"

[lint]
extend-select = ["I"]
select = [
    "F",
    "NPY",
    "UP006",
    "UP007",
    "UP010",
    "UP035",
    "UP036",
    "UP037",
    "UP045",
    "FA100",
]

[lint.per-file-ignores]
"docs/tutorials/*" = ["F401"]
  • ListOrDict was moved to custom_types.py and list_or_dict.py has been removed
  • The Transpiler protocol now distinguishes compiling a single QuantumCircuit and a list thereof type-wise
  • The imports order has been reorganized. In particular, the test module is now correctly imported last, even though pylint doesn't like it, which leads to pylint: disable=wrong-import-order, just like in the Qiskit main repository.

Note that as shown in the ruff configuration, this modernization has been done with the end of life of Python 3.9 in mind. As such, the tests will only pass once the minimum supported Python version is 3.10.

To ease the review process, each task mentioned above has been performed in a separate commit.

@Cryoris
Copy link
Collaborator

Cryoris commented Sep 15, 2025

Thanks for tackling this! I agree with updating the type hints as in qiskit-community/qiskit-optimization#676, but I'm not convinced we need to start enforcing an import sorting -- especially since Python imports can be volatile. Is there any bug that would've been avoided with import sorting? If it's merely stylistic I would prefer not to add this.

@tnemoz
Copy link
Contributor Author

tnemoz commented Sep 15, 2025

Thanks for tackling this! I agree with updating the type hints as in qiskit-community/qiskit-optimization#676, but I'm not convinced we need to start enforcing an import sorting -- especially since Python imports can be volatile. Is there any bug that would've been avoided with import sorting? If it's merely stylistic I would prefer not to add this.

To be fair, the only reason why I also did the import sorting is because it bugged me that the test module was considered as a built-in package by pylint 😄 Would you rather remove the import sorting altogether, or keep the import of the test module at the end with a pylint: disable as in the Qiskit main repo?

AFAIK, I don't see how not sorting the packages may introduce bugs. I don't know whether the PEP8 recommendation is purely aesthetic/for readability purposes or whether something more subtle is going on there.

@Cryoris
Copy link
Collaborator

Cryoris commented Sep 15, 2025

Would you rather remove the import sorting altogether, or keep the import of the test module at the end with a pylint: disable as in the Qiskit main repo?

yeah I think that would be good for now -- if we start enforcing import sorting it would be nice to do this generally in the algorithms and applications packages, not just in a single one

AFAIK, I don't see how not sorting the packages may introduce bugs. I don't know whether the PEP8 recommendation is purely aesthetic/for readability purposes or whether something more subtle is going on there.

I thought there's only a PEP8 for grouping imports as standard imports - 3rd party imports - local imports. But nothing on alphabetical sorting, or is there?

@tnemoz
Copy link
Contributor Author

tnemoz commented Sep 16, 2025

Would you rather remove the import sorting altogether, or keep the import of the test module at the end with a pylint: disable as in the Qiskit main repo?

yeah I think that would be good for now -- if we start enforcing import sorting it would be nice to do this generally in the algorithms and applications packages, not just in a single one

So just to be sure, I should remove the last commit on import sorting but still put the import of the test module in the last blck along with a pylint: disable=wrong-import-order right?

AFAIK, I don't see how not sorting the packages may introduce bugs. I don't know whether the PEP8 recommendation is purely aesthetic/for readability purposes or whether something more subtle is going on there.

I thought there's only a PEP8 for grouping imports as standard imports - 3rd party imports - local imports. But nothing on alphabetical sorting, or is there?

Not that I know of no!

@Cryoris
Copy link
Collaborator

Cryoris commented Sep 19, 2025

So just to be sure, I should remove the last commit on import sorting but still put the import of the test module in the last blck along with a pylint: disable=wrong-import-order right?

Yes! 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants